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(54) System and method for managing a transaction database of records of changes to field 
device configurations 



(57) A computer-based database management 
method permits management of a configuration data- 
base associated with one of a plurality of devices. Each 
device has a variable configuration which includes at 
least one adjustable parameter. The method includes 
the steps of selecting a particular device, selecting a 
particular parameter of the particular device, assigning 
a particular value for the particular parameter at a par- 
ticular time, communicating the particular value for the 
particular parameter to the particular device at the par- 
ticular time, creating a transaction record, and storing 
the transaction record in a configuration database. The 
transaction record includes an identifier uniquely identi- 
fying the particular device and further specifies the par- 
ticular parameter of the particular device, the particular 
value for the particular parameter, and the particular 
time at which the particular value is to be applied to the 
particular parameter. 
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Description 
TECHNICAL FIELD 

5 [0001] The present invention relates generally to database management and, more particularly, to a database man- 
agement system and method for maintaining a database of transaction records for changes made to parameters of 
smart field devices within a process. 

BACKGROUND OF THE INVENTION 

10 

[0002] Typically, process plants (such as chemical refinery plants and drug manufacturing plants, for example) include 
many field devices which control and measure parameters within the process. Each field device may be a control device 
(such as a flow valve controller), a measurement device (such as a temperature gauge, pressure gauge, flow meter, 
etc.) and/or any other device that affects or determines a value associated with a process. Until the past decade or so, 
is field devices have typically been rather simple devices which were controlled either manually or electronically and which 
produced output readings either electronically or on a gauge connected to the device. However, these devices typically 
only provide limited information to a controller such as analog signals pertaining to the readings or measurements 
made by these devices.- 

[0003] More recently, so called "smart" field devices have been developed. Smart field devices are capable of com- 
20 municating with a process controller and/or a management system associated with the device. Typical smart field 
devices are capable of transmitting an analog signal indicative of the value associated with the device, for example, a 
measurement value, and of storing and also digitally transmitting detailed device-specific information, including calibra- 
tion, configuration, diagnostic, maintenance and/or process information. Some smart devices may, for example, store 
and transmit the units in which the device is measuring, the maximum ranges of the device, whether the device is oper- 
as ating correctly, troubleshooting information about the device, how and when to calibrate the device, etc. Furthermore, a 
smart field device may be able to perform operations on itself, such as self-tests and serf-calibration routines. Exem- 
plary smart devices include devices which follow the HART (Highway Addressable Remote Transducer) protocol (HART 
devices), the Fieldbus protocol (Fieldbus devices), the Modbus protocol, and the DE protocol. However, other smart 
device protocols may exist or be developed in the future to support different types of smart devices. 
30 [0004] Currently, every conventional and smart device is capable of performing one or more specific input and/or out- 
put functions with respect to a process. An input function is any function which measures or reads a value associated 
with a process, such as the function performed by a temperature or pressure measurement device. An output function 
is any function that changes something within a process, such as the functions performed by a valve or flow controller. 
Furthermore, some smart devices, such as Fieldbus devices, can perform control functions which are functions asso- 
35 ciated with the control of a process. Each input, output and control subfunction performed by a device is referred to as 
a "Nock/ By def irition. therefore, each device includes at least one. and maybe more, blocks. Fieldbus devices usually 
include multiple blocks (e.g.. one or more input, output, and control blocks), and while HART devices do not include 
blocks, per se. the contents of a HART device are often conceptualized by those skilled in the art as constituting one 
and only one block. 

40 [0005] Each block (a "conceptual" block) and. therefore, each device includes one or more "parameters." A parameter 
is an attribute of a block which characterizes, affects or is s omehow otherwise related to the block. Parameters may 
include, for exarrpie. the type of the block, the maximum operating or measurement range of a block, the mode of a 
block, the value of a block measurement etc. 

[0006] Likewise, each parameter has one or more properties associated therewith, and each of those properties 
45 defines or describes the information within the parameter. For example, the temperature parameter of a temperature 
measuring device has a label property which stores the name of the parameter (e.g., "temperature"), a value property 
which stores the value of the parameter (e.g.. the actual measured temperature), and a units property which stores the 
units in which the temperature value is expressed (e.g., degrees centigrade or degrees fahrenheit). A device or a block 
configuration comprises a set of values for each of the properties of each of the parameters associated with a device 

so or a block " 

[0007] As noted above, smart field devices are developed so that communication therewith must be performed in one 
of several available protocols (the HART and Fieldbus protocols, for example). These protocols allow device manufac- 
turers to provide device-specific types of information for a device and. of course, the particular types of information are 
different for each type of smart field device. Consequently, these protocols are complex and difficult to use in device pro- 

55 gramming. More particularly, some of these protocols do not provide a completely consistent method for communicating 
with every smart device conforming thereto. Instead, these protocols, such as the HART protocol, merely provide a way 
for device manufactures to specify what information is available from each smart field device and how to retrieve that 
information. 
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[0008] Communication with smart devices has been simplified to some extent with the advent of device description 
languages (DDL) and device description services (DD.S) which are provided by the manufacturers of smart field 
devices. A DDL is a human-readable language that provides a protocol for describing the data available from a smart 
device, the meaning of the data associated with the smart device and retrieved therefrom, the methods available for 
5 implementation of the smart device, the format for communicating with the smart device to obtain data, user interface 
information about the device such as edit displays and menus, and for handling or interpreting other information per- 
taining to a smart device. 

[0009] DDL source files comprise human-readable text written by device developers. These files specify all the infor- 
mation available about a device between the device and a bus or a host to which the device is connected. Basically, in 
w developing a DDL source file for a device, a developer uses the DDL language to describe core or essential parameter 
characteristics of the device as well as to provide group-specific, and vendor-specific definitions relating to each block, 
parameter, and special feature of a smart device. 

[0010] A DDL source file is compiled into a binary format to produce a machine-readable file known as a device 
description (DD) which can be provided to a user by the device manufacturer or a third : party developer to be stored in 
is a host system, such as a management system. In some cases, for example in Fieldbus devices, DDL source files may 
be stored in a smart device and transferred from the smart device to a host system. When the host system receives a 
DD object file for a smart device, it can decode and interpret the DD to derive a complete description of the interface 
with the device. 

[0011] DDS is a general software system developed and provided by Fisher-Rosemount Systems, Inc. and/or Rose- 

20 mount, Inc.' for automatically decoding and interpreting the DD's of smart devices. More particularly, DDS is a library of 
routines which, when called by a host, interprets the DD of a smart device to provide the host with information pertaining 
to the smart device, including information pertaining to: (1) the setup and configuration of the smart device; (2) commu- 
nication with the smart device; (3) user interfaces; and (4) methods available for use in conjunction with the smart 
device. One extremely useful application of DDS is in providing a consistent interface between a host system and one 

25 or more smart devices having associated DDL source files (and corresponding DD object files). 

[0012] Although DDS. DDL and DD's are generally known in the art. more information pertaining to the specific func- 
tion and format of DDLs, and of Fieldbus DDL in particular, can be found in the Interoperable Systems Project Foun- 
dation's manual entitled "Interoperable Systems Project Fieldbus Specification Device Description Language" (1993). 
which is hereby incorporated by reference herein. A similar document pertaining to the HART DDL is provided by the 

30 HART foundation. " 

[0013] A management system is a system which interacts with one dr more smart field devices to read any of the 
device, block, parameter, variable, or configuration information associated with those devices. Typically, a management 
system comprises a personal computer having appropriate communication ports which allow it to interconnect to, com- 
municate with, and reconfigure a smart device. Management systems may be on-line, that is, have a hard-wired or other 

35 permanent connection with a smart device, management systems may be portable and capable of being periodically 
connected to a smart device to reconfigure that smart device. 

[001 4] Management systems typically perform a wide variety of functions with respect to smart devices within a sys- 
tem. For example, management systems may be used to provide users with information (e.g.. values of variables or 
parameters) pertaining to the state of a process and to each of the smart field devices associated with or connected to 
40 the process. Management systems may also be used to enable a user to monitor a process and control the process by 
reconfiguring smart devices within the process as necessary. 

[0015] The software routines which are used to perform functions within a management system using features pro- 
vided by the system are typically referred to as applications. Typically, management systems implement applications 
provided by individual smart device manufacturers to implement changes on, and read data from, a particular smart 

45 device. As a result, various applications within a management system often do not share a common or consistent inter- 
face, and the transition from one application to another is therefore cumbersome and time-consuming. Further, smart 
device configuration data, configuration logs, and smart device diagnostic data created and stored by different applica- 
tions are decentralized and cannot be cross-referenced because this data may be stored in diverse formats, in different 
databases and, in some cases, in proprietary formats. Consequently, tasks that could be common to each device within 

so a system must be duplicated in separate applications. 

[001 6] A management system which implements such separately developed applications typically has no way to view 
information pertaining to all the smart devices in a plant or a process simultaneously because the applications for each 
device must be run separately. Furthermore, it is difficult for users to write applications that provide a comprehensive 
view of data pertaining to multiple, different devices in a process because users typically do not have a great familiarity 

55 with DDS or with the DDL and DD's associated with each of the devices within a process. Even if a user does have such 
familiarity, such applications are time-consuming and expensive to develop and must be updated each time a new 
smart device is added to the system. 

[0017] The need for an integrated management system is particularly great in processes or systems which must be 
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certified by government agencies such as the EPA and the FDA, which regulate, for example, certain chemical and 
pharmaceutical processes tc ensure that the products manufactured by those processes meet stringent standards, that 
emissions remain below a predetermined level, and that safety procedures were followed. The easiest way for a plant 
implementing a regulated process to maintain its certification is to maintain records sufficiently thorough to prove to 
5 government auditors that the values of critical process parameters have remained at specified values or within specified 
ranges that comply with the regulatory requirements of interested governmental agencies and safety procedures. An 
integrated management system coupled to the smart devices of a process can be used to automatically record these 
values in a database. Thereafter, the data stored in the database of the integrated management system can be used to 
prove that these critical values remained within respective required ranges. 
w [0018] Previously, whenever a management system changed the state of a field device in the control system (/.e., 
changed any information in the field device), the management system stored, in an internal "state database," a com- 
plete new or current "state" for the device. The "state" of a device includes (1) an indication of the time when the change 
was made {i.e.. when the device was put in the new state) and (2) data corresponding to all information stored in the 
device. The state databases of prior management systems may also have included additional information together with 
75 the states of devices (e.g., information about who made the changes to device states or why. etc.). 

[0019] Maintaining a state database in this fashion, and storing a complete set of variables corresponding to a new 
state every time a change is made to any field device in the control system, requires a significant amount of storage and 
processing time. Further, multiple on-line management systems are typically interconnected, and data from each sys- 
tem is combined to form a unified historical database reflecting the state of the entire control system. Although the pres- 
to ence of an indication in the records of the multiple interconnected state databases of the time corresponding to each 
new state does permit reconciliation of the multiple databases to develop such a unified historical database, it does not 
overcome the well-known inability of prior-art management systems to interface directly with hand-held communicators 
and to then reconcile data transferred to the management system from hand-held communicators into the management 
system database. The reason is that present hand-held communicators, which are quite primitive instruments, do not 
25 have internal real-time clocks and therefore cannot apply a time stamp to the state records that the hand-held commu- 
nicators return to the management system. Consequently, the management system cannot determine the particular 
point in the chronological, historical database at which to insert a record of a given new state received from the hand- 
held communicator in order to reconcile that new state with the existing chronological database. , 
[0020] Integrated management systems also can be used to reconf igure smart devices more regularly to maintain the 
30 certif lability of the process in which the devices are used. Currently, most management systems which support more 
than one smart field device include particularized software written for each supported smart device to allow communi- 
cation with that smart device. Adding a new smart device to a process therefore requires the management system for 
that process to be reprogrammed. Once again, this programming is time-consuming and can be expensive because it 
must be performed by a person knowledgeable not only in the management system software, but also in the smart 
35 device protocol and the new smart device. 

[0021] Although hand held communicators exist which interface with different smart devices following a particular pro- 
tocol, these devices only read and write data from and to the device and are not capable of processing that data in any 
significant manner. 

[0022] Another cumbersome aspect of application development is programming an application to perform the numer- 
40 ous tasks relating to and necessary for communication between a user and each smart device within a system. A devel- 
oper not only must be attentive to details involving how to communicate with each separate device, but that developer 
must also pay particular attention to how information is presented to a user via, for example, a display. This task is made 
more difficult because typical applications do not use consistent user interface protocols. Each of these functions 
requires much programming time and effort, which must be repeated each time a new smart device is added to the sys- 
45 tern. 

[0023] Still furtherrapplications typically^ low a user to view a current configuration of a device.- block, or parameter 
within a process, but those applications do not allow the user to view past configurations or to display multiple configu- 
rations simultaneously to compare such configurations. 

so SUMMARY OF THE INVENTION 

[0024] According to one aspect of the present invention, a computer-based database management system is pro- 
vided for managing a configuration database associated with one of a plurality of field devices, each of which has a 
changeable configuration which includes at least one adjustable parameter. The system includes initializing means for 
55 setting the adjustable parameter to a first value at a first time, updating means for setting the adjustable parameter to a 
second value at a second time, and a transaction memory responsive to the initializing means and the updating means 
for storing a plurality of transactions. Each transaction includes a particular value of a particular adjustable parameter 
and a corresponding time at which the particular adjustable parameter attains the particular value. 
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[0025] In accordance with another aspect of the present invention, a computer-based database management system 
is provided for managing a configuration database associated with one of a plurality of devices, each of which has a 
variable configuration including at least one adjustable parameter. The system includes first selecting means for select- 
ing a particular device, second selecting means for selecting a particular parameter of the particular device, assigning 

5 means for assigning a particular value for the particular parameter at a particular time, means coupled to the assigning 
means for communicating the particular value for the particular parameter to the particular device at the particular time, 
and recording means for creating a transaction record. The transaction record includes an identifier uniquely identifying 
the particular device and further specifies the particular parameter of the particular device, the particular value for the 
particular parameter, and the particular time at which the particular value is to be applied to the particular parameter. 

w The system further includes means for storing the transaction record in a configuration database. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0026] 

Fig. 1 is a block diagram illustrating the interconnections between a process, a digital control system and a man- 
agement system; 

Fig. 2 is a block diagram of the management control system of Fig. 1 having a device communication interface and 
controls which operate according to the present invention; 
20 Fig. 3 is an upper hierarchy of object information according to the present invention; 
Fig. 4 is a lower hierarchy of object information according to the present invention; 

Fig. 5 is a diagrammatic view of the FMS database of Fig. 2 illustrating a transaction database included therein; 
Fig. 6 is a diagrammatic view of a record of the transaction database of Fig. 5; 

Figs. 7-10 are flowcharts illustrating programming for a transaction database management system and method in 
25 accordance with the present invention; 

Fig. 1 1 illustrates the control block of Fig. 2; 

Fig. 12 is a flowchart illustrating the initialization steps associated with a control constructed according to the 
present invention; 

Figs. 13-19 are flowcharts illustrating the operation of a control according to the present invention; 
30 Fig. 20 is a screen display which can be generated by a set of device controls in accordance with the present inven- 
tion; 

Fig. 21 is a screen display which can be generated by a set of parameter controls according to the present inven- 
tion; 

Fig. 22 is a screen display which can be generated by a set of block controls according to the present invention; 
35 Fig. 23 is a screen display which can be generated by a set of timeline and parameter controls according to the 
~ present invention; and 

Fig. 24 is a flowchart illustrating programming for reconstructing an expected device state from the transaction 
database of Fig. 5. 

40 DETAILED DESCRIPTION 

[0027] Fig. 1 illustrates a management system 10, referred to hereinafter as a Field Management Solutions system 
(an FMS system), interconnected with a process 12, a digital control system 14 (DCS) which controls the process 12, 
and a further management system such as another FMS system 15. The process 12 may comprise any desired type 

45 of process, such as a manufacturing or refinery, process, etc., and is illustrated as including four smart field devices, 
including three HART devices 16. 18 and 20 and one Fieldbus device 22, and a conventional {i.e., non-smart) device 
24. The devices 16, 18, 20, 22 and 24 are controlled in any desired manner by the digital control system 14. 
[0028] Generally, the FMS system 10 is a PC-based software tool that includes applications which perform field- 
device management tasks. The FMS system 1 0 integrates device management for each of the devices within the proc- 

so ess 12 by helping users to, for example, configure, calibrate, monitor and troubleshoot any and all of the smart field 
devices associated with the process 12. 

[0029] The FMS system 10, which may comprise any type of computer- or microprocessor-based system, may 
include a display 30, a printer 31. a keyboard 32 and a mouse 34 connected to an operating system and CPU 36. A 
memory 38 having an FMS database 40 is coupled to the operating system and CPU 36. The memory 38. including the 
55 FMS database 40, stores software and data used by the FMS system 10 in performing tasks related to displaying infor- 
mation to a user via the display 30 or the printer 31 and communicating with the smart devices 16, 18, 20 and 22. In 
addition, the FMS database 40 stores device-related information which is not available from the smart devices, for 
example, information pertaining to past configurations of the devices, information pertaining to off-line devices, such as 
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off-line smart devices and conventional devices, and information pertaining to service notes including when the next 
service is needed; who performed service procedures; any favored replacement devices, etc. Data pertaining to off-line 
smart devices may be stored within the database 40 in a format identical to the format in which that data is actually 
stored within the off-line devices so that, to the FMS system 1 0, off-line devices appear to be available through the data- 

5 base 40 in the same way they would be available if those devices were on-line. 

[0030] The smart devices 16, 18 are on-line devices which are connected to the FMS system via a communication 
line 42 and a modem 44. The smart device 22 is an on-line device which is connected to the FMS system via a Fieldbus 
. Interface 45. The smart device 20 is an off-line device which is not permanently connected to the FMS system 10. How- 
ever, the smart device 20 may communicate with the FMS system 10 via a hand-held communicator and/or secondary 

w (laptop) FMS 46 which, as described in more detail below, may be periodically connected to the device 20 and/or any 
of the other smart devices to read data from, and write data to, the device 20 and/or the other smart devices. Thereafter, 
the hand-held communicator and/or secondary FMS 46 may be connected to the FMS system 10 to upload data per- 
taining to the smart device 20 and/or any other smart devices to which it was attached and store such data in the FMS 
database 40. 

is [0031] rf desired, the operating system and CPU 36 of the FMS system can be connected through, for example, an 
ethernet communication link 48 and/or other network link to the digital control system 14 and other FMS systems, for 
example, the other FMS system 15. 

[0032] Fig. 2 illustrates the interconnections between various component parts of the FMS system 10, including hard- 
ware and software components, and will be used to describe how the various software components stored in the mem- 

20 ory 38 of the FMS system 10 interact with each other, with the display 30, the printer 31 . the keyboard 32, the mouse 
34, the FMS database 40 and the smart devices within the process 12. It is understood that the software components 
of the FMS system 10 are stored in the memory 38 and are run on the operating system and GPU 36. 
[0033] The FMS system 10 preferably operates in a Microsoft Windows environment (such as a Windows 95™ envi- 
ronment) and, therefore, includes a standard Windows operating system 46, which is used to display data and informa- 

25 tion on the display 30 and the printer 31 and to retrieve data and information from the keyboard 32 and the mouse 34. 
Thus, information provided to, or retrieved from, the Windows operating system 46 is preferably provided in a standard 
Windows call format of any desired type, as is known to those skilled in the art. However, the FMS system 10 could be 
implemented according to the present invention using any other desired Windows-based or non-Windows-based inter- 
face format (whether or not a graphical user interface) including, for example, Macintosh. Xwindows or IBM DOS fbr- 

30 mats. 

[0034] The FMS system 10 includes a set of FMS applications 50 comprising core applications 52 and add-on appli- 
cations 54. The core applications 52 are essentially programs written by the FMS system provider to perform predeter- 
mined and frequently used operations. The add-on applications are applications which are developed by a user or a 
third-party developer and imported to the FMS system 10 to perform customized functions. 

35 [0035] As used hereinafter, an application refers to any software routine implemented by the FMS system 10 which 
displays to a user information pertaining to or about the process 12 or one or more devices, blocks, parameters, or other 
information associated with the devices connected to. or associated with, the FMS system 10, and/or which allows a 
user to reconfigure one or more of the devices associated with or connected to the FMS system 10. The information 
used by an application typically is either stored in. or developed by. the smart devices within the process 12. or is stored 

40 in the FMS database 40. 

[0036] Thus, for example, the FMS system 10 may include core or other applications which allow a user to interact 
with the data within the FMS database 40 and/or the smart devices within the process 12 to view the present state of 
one or more of the devices within the process 1 2, to change the configuration of one or more of the smart devices within 
the process 12. to view multiple devices in a simultaneous or sequential manner, to perform common smart device con- 

45 trol and configuration functions, to run browsers that locate devices on the network, to monitor the status of devices and 

generate alarm listsrand to implement device calibration and testing routines. — 

[0037] Other typical core applications may include configuration applications, configuration-management applica- 
tions, alarm scanning applications, history event-log applications, reporting applications, trend-analysis applications 
and diagnostic applications. A configuration application displays the values of the variables associated with one or more 

so parameters of a device within a process and allows a user to change appropriate ones of those parameter values. A 
configuration management application allows a user to manage the configuration of the device as a whole, for example, 
resetting a device, initializing a device, and calibrating a device. An alarm scanning application checks all of the devices 
being serviced by the FMS system 10 to determine if those devices are operating correctly or if an error has occurred 
within any of the devices. A history event-log application provides an event log having, for example, user log-in informa- 

55 tion. time-stamped messages which indicate changes that have been made to the configurations of the devices being 
serviced by the FMS system 10, alarms associated with the devices being serviced the FMS system 10 and other 
events. A reporting application automatically generates a report showing, for example, all past, present or desired future 
configurations of one or more devices. A trend-analysis or "trending" application records data measured by devices 
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within the process 12 to identify trends which may be occurring within particular devices or across a process as a whole. 
As is evident, any other desired applications can be created and provided to the FMS system 10. 
[0038] During operation of the FMS system 10, a user selects one or more of the applications for execution. The 
selected application is identified in Fig. 2 as the current application or applications 56. Because multiple applications 

5 may be executed simultaneously by the FMS system 10, there may be multiple current applications 56. Any current 
application 56 may interface directly with the Windows operating system 46. an interface block 58, a digital control inter- 
lace (DCI) 60 and an FMS database interface 62. If desired, the current application 56 can also interface with an Open 
DataBase Connectivity (ODBC) block 64 (a well-known Microsoft database application interface (API) system that ena- 
bles communication with nearly all databases) and a server network 65. For many applications, however, such connec- 

w tions are not necessary or desirable. Furthermore, any current application 56 may indirectly interface with the Windows 
operating system 46, the smart devices within the process 12, and the database 40 via the interface block 58. 
[0039] The interface block 58 is essentially a software package having for example, specifically configured Windows 
custom controls. OCX controls or VBX controls, which automatically perform functions relating to the communication of 
particular, frequently used information between a current application 56, the smart devices within the process 12, the 

is database 40. and a user interface 65 comprising the Windows operating system 46, the display 30, the printer 31, the 
keyboard 32, and the mouse 34. The interface block 58 can be used by" a current application 56 to perform these inter- 
facing functions without the application designer knowing the specifics of the protocols involved therewith. As a result, 
the interface block 58 enables an application to be designed more easily and provides a consistent user interface. 
[0040] Preferably, current applications 56 and the interface block 58 interface and communicate with the smart 

20 devices within the process 12. other FMS systems or digital control systems and/or the database 40 through the DCI 
60 and a server network 66 comprising servers 68 and 70. While typically the server network 66 will be located in, and 
associated with, the FMS system 10, the dotted line between the DCI 60 and the servers 68 and 70 in Fig. 2 indicates 
that the DCI 60 can also access server networks of other FMS systems through, for example, the ethernet connection 
illustrated in Fig. 1. 

25 [0041] Essentially the DCI 60 is a convenience layer which comprises a library of routines which perform functions 
necessary for communicating with, and retrieving data from, and other functions pertaining to the database 40. the 
smart devices associated with the process 1 2 and/or other FMS systems. In operation, the DCI 60 converts commands 
and messages sent from the current application 56 and the interface block 58 into a format recognized and used by 
server network 66 and, likewise, converts data provided by the server network 66 into a form recognized and used by 

30 the current application 56 and the interface block 58: 

[0042] While the DCI 60 can use any desired protocol to perform these communication functions, the DCI 60 prefer- 
ably uses an object-oriented protocol and, most preferably, uses an object linking and embedding protocol such as the 
Object Linking and Embedding (OLE) protocol developed and documented by Microsoft, Inc. The Microsoft OLE (2.0) 
protocol is used in the Microsoft Windows 95™ operating system and is well-known in the art. 

35 [0043] Generally, an object-oriented protocol is a programming paradigm which models the world as a collection of 
self-contained objects that interact by sending messages. Objects include data (a state) and methods (algorithms) that 
can be performed on the data. In addition, objects are related to one another through an interface connection and may 
communicate with other objects in the hierarchy through messages. When an object receives a message, it responds 
by using its own methods which are responsible for processing the data in that object and sending messages to other 

40 objects to perform specific tasks and possibly return appropriate results. 

[0044] Because the DCI 60 communicates with the server network 66 through an OLE hierarchy, the DCI uses stand- 
ard OLE procedures or calls relating to reading and writing values of OLE objects, enumerating a set of enumerated 
values in an OLE object, getting and setting properties in OLE objects, calling and implementing methods of OLE 
objects and retrieving property data stored in the OLE collection objects in conjunction with OLE Item methods (a par- 

45 ticular type of OLE method). However, other OLE procedures can be implemented by the DCI 60 on OLE objects to 

- communicate.withJhe.server_network_66 _ ~ - . 

[0045] As described in more detail below, the particular OLE hierarchy which is preferably used by the FMS system 
10 is an OLE object hierarchy which has been developed to categorize all of the different types of information and the 
interrelationships between the different types of information available for, or used by. each of the different DDL f s asso- 

so ciated with each of the DD's which, in turn, are associated with the devices within the process 12 being serviced by the 
FMS system 10. This determined hierarchy defines a set of OLE objects, each of which stores a particular set of prop- 
erties as defined by the hierarchy and a particular set of methods which can be used to manipulate the property data 
and to communicaie with other OLE objects according to the relationships defined by the hierarchy. Tnis hierarchy will 
be discussed in more detail in conjunction with Figs. 3 and 4. 

55 [0046] Essentially, the DCI 60 communicates with the server network 66 as if all the OLE objects identified for the 
determined hierarchy exist within the memory of the server network 66. The DCI 60 implements a simple set of calls 
necessary for communicating with the OLE objects in the OLE protocol. In reality, however, the data and methods of 
each OLE object are not actually stored or placed in the memory of the server network 66 until a call, such as a read 
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or write call, is sent to the server network 66 for such OLE object by. for example, the DCI 60, the DDS 72. the smart 
device communication network 74, or the FMS database interface 80. At that time, the server network 66 recognizes 
that the data and methods pertaining to the OLE object must be retrieved and stored in memory associated with one of 
the servers 68 or 70 and automatically performs the functions necessary to retrieve the data and methods of that OLE 
object. 

[0047] When the server network 66 receives a call relating to the reading or writing of data or methods within one of 
the OLE objects stored in its memory, the server network 66 returns the requested information or performs the 
requested function to the OLE object data according to its stored routines so as to read data from, and write data to, the 
OLE object, the DDS 72, the smart devices within the process 12 and the FMS database 40. 

[0048] Likewise, the DCI 60 recognizes or receives changes in OLE objects stored within the memory associated with 
the server network 66 and performs functions based thereon to implement communication with the current application 
56 and the interface block 58. The server network 66 interfaces with the OLE objects in the determined OLE hierarchy 
and includes a device server 68 and a database server 70. The device server 68 is essentially a set of software routines 
which have a specified correspondence with the set of OLE objects in the determined OLE hierarchy. These routines 
are specifically developed to communicate with a DDS 72, a smart device communication interface 74, and the OLE 
objects of the defined hierarchy. Such routines may, for example, transmit, retrieve, and change particular types of data 
and information stored within, or available from, the smart devices within the process 12 and/or from DD's (which are 
files) associated with the smart devices within the process 12. Likewise, the database server 70 is essentially a set of 
software routines associated with the OLE objects in the determined OLE hierarchy. These routines communicate with 
the DDS or API 72 and/or an FMS database interface 80 to, for example, transmit, retrieve, or change particular types 
of data and information stored within, or available from, the FMS database 40 and/or from the DD's which are associ- 
ated with the smart devices for which data is stored in the FMS database 40. As indicated in Fig. 2. the DD's used by 
the DDS 72 are stored in a device description library 76 coupled to the DDS library 72. 

[0049] The routines of the servers 68 and 70 are associated with each of the OLE'objects in such a way that the rou- 
tines which perform the particular read functions required for retrieving the data of an OLE object from the DDS 72. from 
smart devices, or from the database 40 are automatically implemented by a request for such data from the DCI 60. Like- 
wise, the routines of the servers 68 and 70 are associated with each of the OLE objects in such a way that the routines 
which perform the particular writing functions required for changing the configuration 6f smart devices or storing infor- 
mation in the database 40 are automatically implemented by a request to write such data in the OLE object. 
[0050] For example, a request made by the DCI 60 to write the value property within an OLE object representing data 
within or associated with a smart device will cause the server 68 to implement the routine which writes new property 
values to the smart device. Likewise, a request to read from any OLE object property values stored in, or associated 
with, a smart device will automatically call the server routine which retrieves the property values associated with that 
OLE object from the DDS and/or the smart device and store such property values in the memory (not shown) associ- 
ated with the server 68 as the OLE object. Similarly, a request made by, for example, the DCI 60 to write the property 
valueswithin an OLE object associated with data stored in the database 40 will automatically implement the server 70 
routine which writes new property values to the locations within the database 40 with which that OLE object is associ- 
ated. Likewise, a request to read property values from an OLE object will cause the server 70 to retrieve the data asso- 
ciated with that OLE object from the DDS and/or the location in the database 40 associated with those property values 
and store such property values in the memory (not shown) of the server 70 as the OLE object 
[0051] These server routines are simple, straightforward, and easy to write by those skilled in the art and thus are not 
provided herein. However, those familiar with OLE and DDL's can create such routines in a straightforward manner 
using any desired programming language. If desired, the routines may be written or optimized in any desired way to per- 
form in as high-speed a manner as possible to thereby increase the operating speed of the current application within 
the FMS system 10. 

[0052] Generally, to retrieve specific data from, or pertaining to. one of the on-line devices of the process 12, the 
server 68 asks the DDS 72 for the specific data. If that data is stored in the DD for a smart device, the DDS 72 then 
consults the DD for the referenced device or the DD associated with a block of the referenced device and returns the 
requested data to the server 68. 

[0053] If the specific data was available from the DD, the server 68 stores and maintains that data in the OLE object 
to which the retrieved data is related. If however, the requested specific data is not available from the DD for a device 
or a block of a device but is stored, instead, in the on-line device, the server 68 sends a command to the smart device 
communication interface 74 (which may comprise any known smart device communication interface including, for 
example, a Fieldbus device interface developed by Sotting, a German company located in Karlsruhe, or the HART 
device interface of Micromotion, located in Boulder. Colorado) to retrieve the specific data from the on-line device. 
[0054] The smart device communication interface 74 then sends a request to the DDS 72 for information on how to 
get the specific on-line device for the data requested by the server 68. The DDS 72 retrieves this instruction information 
from the DD for the on-line device and returns the instruction information to the smart device communication interface 
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74 which, in turn, sends a proper request to the on-line smart device. The smart device then responds with a data 
stream including the specific data. The smart device communication interface 74 then sends a request to the DDS 72 
for information on how to interpret the data stream received from the on-line smart device. The DDS 72 then retrieves 
interpretation instructions from the DD for the on-line smart device and returns them to the smart device communication 
5 interface 74 which, in turn, interprets the data stream from the on-line device in accordance with the interpretation 
instructions in order to extract the specific data requested by the server 68. The smart device communication interface 
then returns the specific data to the server 68 which provides the retrieved data to the OLE object with which that data 
is associated. 

[0055] The process of writing data to an on-line device is similar to the process of reading data from that device except 
w that the server 68 first sends a request to the DDS 72 for write information, e.g.. whether the data is writable, what type, 
what specific values, and what range of data can be written, etc. If the data is writable, the server 68 sends a write com- 
mand to the smart device communication interface 74 which, in turn, interfaces with the DDS 72 for write protocols for 
the on-line device and sends the proper write command to the on-line device in response to the information. The smart 
device communication interface 74 can also intef pret other data from the on-line devices; such as write verifications, 
is response codes, data or value changes which occui in the device, etc. and sends such data to the server 68 for storage 
in the proper OLE object. ' 

[0056] In some instances, the DDS 72 will inform the server 68 that ft needs more information to answer a request for 
data. For example, the DDS 72 may determine that the handling property of a parameter (i.e., whether the parameter 
is readable and/or writable) is dependent on the mode parameter of a particular device. The DDS 72 sends a request 

20 to the server 68 for the mode parameter of the device. In response thereto, the server 68 sends a request for the mode 
parameter of a device to the smart device communication interface 74 which operates as described above to retrieve 
the mode parameter of the device. When the server 68 receives the mode parameter of the device from the smart 
device communication interface 74, it sends this information to the DDS 72 which, thereafter, determines the handling 
property of a parameter of a device and returns such property to the server 68 which, in turn, places that value in the 

25 proper OLE parameter object. 

[0057] Communication between the server 70. the DDS 72 and the FMS database interface 80 is similar to that 
described above, except that the FMS database interface 80 is programmed to read and write information to and from 
the FMS database 40 instead of a smart device. Generally, however, the FMS database interface 80 mimics the func- 
tions of the smart device communication interface 74 as they relate to communications between the DDS 72 and the 

30 server 70. .. 

[0058] It is possible to have the FMS database interface 80 store information pertaining to, for example, values asso- 
ciated with off-line devices and data pertaining to changes made to on-line and off-line devices in the database 40 in a 
DDL format, i.e., in a format that mimics how such data is stored in on-line devices. In such a situation, the FMS data- 
base interface 80 may need to access the DDS 72 to determine how the data is stored in the FMS database 40. For 

35 example, in some instances, the database 40 stores parameter values, such as past parameter values in order to, for 
example, mimic the state of a device. Conseque ntly, the F Mg database interface 80 may have to access the DDS 72 to 
retrieve this information to know what type of data is stored in the database, /.e.. integer, enumerated, etc. However, 
information stored in the database 40 need not be stored in a DDL format. Therefore, to service a command from the 
server 70 to read data from, or write data to. the database 40, the FMS database interface 80 may not need to access 

40 the DDS 72 for device values. Instead, the FMS database interface 80 may write data to, and read data from, the data- 
base 40 directly. 

[0059] The FMS database interface 80 is preferably an application program interface (API) of any conventional type 
which is specifically set up and configured for retrieving information from the database 40 according to any desired or 
known method. Thus, the FMS database interface 80 automatically keeps track of where and how data is stored in. and 

45 retrieved from the database 40. 
- "[0060]— As-indicated above, the current application 56 and. if desired, the interface block 58 can also interface with the 
database 40 through the FMS database interface 62 and the ODBC block 64. The FMS database interface 62 may com- 
prise any desired or known applications program interface (API) having a library of routines developed to convert data 
and requests from a format recognizable or used by the current application 56 into a form recognizable and usable by 

so the ODBC block 64 and vice-versa. Using the FMS database interface 62 (API) to write to the database 40. as opposed 
to using the ODBC block 64 directly, helps maintain database integrity and consistency and makes applications easier 
to write because the application is then shielded from database management. Typically, the FMS database interface 62 
and the ODBC block 64 (or any other open database accessing system) will be used when an application needs to store 
data in the database 40 in a format that is inaccessible or incompatible with the OLE object hierarchy communication 

55 scheme discussed herein. 

[0061] Figs. 3 and 4 illustrate a particular hierarchy of OLE objects which has been developed to represent all of the 
information defined within or available from one or more DDL's, a set of smart devices which follow the protocols of 
those DDL's and a database which stores information related to devices using those DDL's. The hierarchy of Figs. 3 
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and 4 also represents the relationships between those OLE objects. This hierarchy can be used within an OLE environ- 
ment to enable an application to retrieve information associated with a DDL, smart devices which use that DDL, and a 
database which stores information pertaining to smart devices which use that DDL Thus, the hierarchy of Figs. 3 and 
4 represents not only an arrangement of DDL information (/.e., information available from DD's of DDLs and/or infor- 
5 mation available from a device or a database associated with devices using one or more DDLs), but also a way of defin- 
ing an interlace between the DCI 60 and the servers 68 and 70 of Fig. 2 in order to access, retrieve, and change this 
information. 

[0062] Each of the OLE objects in the hierarchy of Figs. 3 and 4 is preferably an OLE automation object and is repre- 
sented as an oval having the type ol OLE object identified therein. Each of the OLE objects of Figs. 3 and 4 includes, 
10 or is associated with, a subset of the information defined within or used by one or more DDLs and available from DD's, 
smart devices and databases which store information pertaining to smart devices. 

[0063] Generally, each of the OLE automation objects of Figs. 3 and 4 includes properties (or attributes), methods 
and interfaces. Because the OLE objects within Figs. 3 and 4 are automation objects, they have an IDispatch interlace 
(a well-known interface of the OLE protocol) associated therewith. The IDispatch of the OLE automation objects of Figs. 
15 3 and 4 can be used by, for example, the DCI 60 and the server network 66 to retrieve information pertaining to the prop- 
erties and the methods of that OLE object and to communicate with other OLE objects. 

[0064] The properties of an OLE object comprise data. pertaining to the objects. Each property also has functions 
which can be used, for example, to get the property value and to set the property value of the OLE object Example OLE 
object properties include the name of the object, a count of the number of items within or associated with the object, a 
20 label associated with the object, and help associated with the object. 

[0065] OLE object methods perform actions on OLE objects, or on the data in OLE objects, implement particular rou- 
tines using the data in OLE objects, and communicate with other OLE objects. For example, a method may enumerate 
a set of values in other OLE objects. Together, the properties and the methods of an OLE automation object define the 
programmable interface of that OLE object accessible by the server network 66 and the DCI 60. 
25 [0066] The hierarchy of Figs. 3 and 4 comprises an upper hierarchy, illustrated in Fig. 3, and a lower hierarchy, illus- 
trated in Fig. 4. The upper hierarchy of Fig. 3 corresponds to and illustrates the physical or defined connectivity of 
devices such as HART. Fieldbus. and other smart or conventional devices, and blocks, such as Fieldbus blocks, con- 
nected within a process. The lower hierarchy of Fig. 4 illustrates relationships among the data which is available from, 
or referenced by, DDLs such as the HART and Fieldbus DDLs, and the data which is stored in and/or available from 

30 DD's, smart devices and/or a database pertaining to smart or other devices. 

[0067] In order to facilitate a complete understanding of the hierarchy of Figs. 3 and 4, a table (entitled "OLE Object 
DDL Equivalents") is provided at the end of the present specification. The OLE Object DDL Equivalents table identifies, 
for each of the OLE objects illustrated in the lower hierarchy of Fig. 4, the functionally equivalent data, definitions and/or 
constructs of the Fieldbus DDL that correspond to the OLE object. It should be recognized, however, that the OLE 

35 objects of Figs. 3 and 4 similarly have functionally equivalent types of data, definitions, and constructs available in other 
DDLs, such as the HART DDL, and that the hierarchy of Figs. 3 and 4 therefore can be applied to any DDL Another 
table (entitled "OLE Object Definitions"), also appearing at the end of the present specification, provides a list of some 
important properties and methods associated with each of the OLE objects illustrated in Figs. 3 and 4, and provides a 
short description of those properties and methods. 

40 [0068] Once again, the properties of the OLE objects of Figs. 3 and 4 represent, and correspond to/similar types of 
data available from, or defined by, DDLs (for example, the HART and Fieldbus DDLs) because, as noted above, the 
OLE objects of Figs. 3 and 4 have been developed to map onto and represent the data available from or defined by 
these DDLs. Thus, for example, the Block object of Fig. 3 represents and corresponds to the block entity recognized 
and used by the Fieldbus DDL. while the Device object of Fig. 3 and the Parameter object of Fig. 4 represent and cor- 

45 respond to the device and parameter entities, respectively, recognized and used by both the HART and Fieldbus DDLs. 

The methods identified-in the OLE-Obj eel-Definitions table are standard OLE-methods. 

[0069] Each OLE object within the hierarchy of Figs. 3 and 4 can be accessed or defined by traversing a path through 
the hierarchy to that OLE object. Beginning at the top of Fig. 3, every path through the hierarchy of Figs. 3 and 4 
includes a Root object. Root objects define, among other things, the ViewTime to which the data within any of the OLE 

so objects below the Root object pertains. More specifically, the Root object is associated with a ViewTime, which may be 
"past." "present." or "future" and, in some instances, which specifies a particular time. If the ViewTime is present, the 
time is the actual time. If the ViewTime is past, the time may be set to any historical time but. preferably, is set to a time 
at which a change was made to one or more parameter values. Preferably these changes are stored in the database 
40 in. for example, an event log. If the ViewTime is future, the time may be set to any future time or may be set to indi- 

55 cate only that it refers generally to the future. 

[0070] The Item method of the Root object includes a set of collections, as identified in the OLE Object Definitions 
table, which defines the next layer in the hierarchy of Fig. 3. Generally, the collections of the Hem method of an OLE 
object define interconnections between that OLE object and the OLE objects below that OLE object within the hierarchy 
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of Figs. 3 and 4. Each collection of an Item method of an OLE object is illustrated in the hierarchy of Figs. 3 and 4 by 
the quoted name of that collection below the OLE object which includes that collection. The generic name of the mem- 
bers within a collection are identified in the hierarchy of Figs. 3 and 4 by unquoted and underlined expressions located 
beneath the OLE object associated with the collection type and above the OLE object which has information pertaining 

5 to this expression as one of the properties thereof. 

[0071] Thus, for example, the Root object has a collection of BlockTag objects (identified as the "BlockTag" collection), 
each of which has a particular name illustrated generally in Fig. 3 as Block Tag . Generally, a block tag is a unique iden- 
tifier assigned to a particular block within the FMS system by a technician installing/configuring the FMS system in order 
to identify a particular block. A BlockTag object having a name of Block Tag , therefore, uniquely defines a Block object, 

w as illustrated in Fig. 3. As is evident, the actual number of BlockTag objects within the hierarchy of Figs. 3 and 4 is 
dependent on the number of blocks (as that name is used in the Fieldbus DDL protocol) connected to or associated with 
the FMS system 10. 

[0072] The PhysicalTag. DevicelD. and DeviceTag objects relate to or are associated with the "PhysicalTag," "Devi- 
celD," and "DeviceTag" collections of the Root object, respectively, and are used to uniquely define a particular device 

is connected to or associated with the FMS system 10. A device ID typically includes a triplet of information comprising 
the name of the device manufacturer, the model number of the device, and the serial number of the device. Device tags 
and physical tags usually refer to a location of the device in a plant or a process such as the process 12. The value of 
a physical tag and/or a device tag can be, for example, an alphanumeric code associated with a specific physical loca- 
tion in the plant or any other description of a physical location. For HART devices, the physical tag is considered the 

20 same as the device tag whereas, for Fieldbus devices, the physical tag can have a different value than the device tag. 
The OLE objects in Figs. 3 and 4 immediately below a quoted collection name, such as the PhysicalTag object, the 
DeviceTag object, and the DevicelD object, are also referred to as collections because they are related to constructs 
which a DDL considers or defines as collections. 

[0073] In lieu of. or in addition to having a device tag. a physical tag and/or a device ID, a device can be identified by 
25 its physical communication connection to an FMS system. Specifically, each device is connected to an FMS network 
(illustrated in Fig. 3 by the Network object which is a "Net" collection of the Root object) through one of a number of 
networks, each of which is identified generically by the expression TCP/IP Node Name. 

[0074] Each network includes a series of nodes, identified in Fig. 3 by the NetNode object. A network node includes 
a set of ports (illustrated by the Port object) which may have names of, for example, "Comr or "Com2\ The port may 
30 connect to a device through a modem (identified by the Modem object) and at one of sixteen station addresses, each 
nf whirh ifi identified by a different Station Address . 

[0075] The port of a network node may also connect to a device through one or more HART interface units (HIU's) 
(identified by an HIU object) having a Station Address . Each HIU includes one or more interchanges (identified by the 
Interchange object) each of which typically includes 8 lines identified by Line Number. Interchange objects also include 
35 a method (which, contrary to the above-stated general rule about quoted names, is identified by the label "Block") which 
returns an interface to the particular Block object that describes the HIU. 

[0076] A network node can also be coupled to a device through one or more different DCS's, for example, the RS3, 
Provox, or other DCS's. Although Fig. 3 illustrates each of these as connected through a generic DCS object, the actual 
connection to an RS3 DCS. tor example, would be made and could be identified in Fig. 3 by a node number, a card 
40 number, a port (typically one of four ports in a card) and a line (typically four lines per port). However, because the con- 
figurations of these DCS systems are not yet fully d evelo ped, the actual connections with each are not shown and the 
DCS object is not mentioned in the OLE Object Definitions table. 

[0077] Furthermore, a network node may be coupled to one or more Fieldbus interface cards. However, because the 
Fieldbus devices are not yet being sold, the exact connection to a device is not yet known and, therefore, this connec- 
45 tion is not represented in the hierarchy of Fig. 3. However, such a Fieldbus connection could easily be added by showing 
a Fieldbus object and any other OLE objects related to the components required for a Fieldbus connection from 
between a network node and a device between the NetNode object and the Device object. 

[0078] Once a device is identified in any manner specified above, a block within the device can be uniquely deter- 
mined by the Tag" collection, illustrated as the Tag object, having the HART Tag name. H the device is a HART device, 
so the contents of which are represented by only one conceptual block, the block is already uniquely identified and can 
simply be specified by the "HART" collection. The names of the tags related to the Tag object are specified as HART 
lag in Fig. 3 because the HART tag of HART devices is used as this identifier. However, other tags for other types of 
devices could be used instead. 

[0079] As suggested above, a Block object and. correspondingly, a block of a process, can be uniquely identified by 
55 traversing any of the above defined paths through the upper hierarchy of Fig. 3. Likewise, every other OLE object within 
the hierarchy of Figs. 3 and 4 can be identified by a unique moniker derived by traversing a path from the Root object 
at the top of the hierarchy of Fig. 3 through to the particular OLE object. Thereafter, the properties and methods of any 
of the OLE objects within the hierarchy of Figs. 3 and 4 can be referenced and obtained using the moniker developed 
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for that OLE object. 

[0080] More particularly, a moniker can be deter mined from the hierarchy of Figs. 3 and 4 by compiling a string com- 
prising the quoted and the unquoted/underlined expressions encountered in traversing a path from the Root object in 
Fig. 3 to the OLE object of interest, and seperating these expressions with an exclamation point f !")■ F<* example, the 
5 moniker for a Block object can be any of the following: 

Root lBlockTaal Block Tag l 
Root lPhvsicalTaQi HARTTaQ lTaoi HARTTaa 
Root tDevicelDI Uniaue Identifier lHART 
10 BofiltNetiTCP/IP Node NametEflfl 

Name ! Modem '. Station Address lTagl HART Tag 

[0081] As will be evident, monikers for other OLE objects illustrated in Figs. 3 and 4 can be developed using this for- 
mat. The "NamedConfig" collection of the Root object of Fig. 3 (represented by the NamedConfigs object) relates to 

is objects which are stored in the FMS database 40 and which are not available from a device. Each NamedConfigs object 
is identified by a ConfiaName to specify a particular NamedConfig object. A NamedConfig object may include, for 
example, a "recipe" or particular configuration of a block necessary for implementing a particular function within a proc- 
ess, a past configuration of a block within a process, or for that matter, any other desired user information related to 
Block objects'. However, to the server network 66 of Fig. 2, each NamedConfig object looks similar to a Block object 

20 except that the parameter value data of a NamedConfig object is retrieved from the FMS database 40 as opposed to 
being retrieved from a device. NamedConfig objects may have a subset of the information typically associated with a 
Block object. 

[0082] The lower hierarchy of Fig. 4 illustrates an inter-relationship among the data associated with each block of a 
system. Therefore, as illustrated in Fig. 4, each Block object (and each NamedConfig object) includes a set of collec- 
ts tions denominated "Param," "Unit/ "Database/ "Refresh." "ItemArray/ "Collection/ "Menu/ "Method," "EdrtDisplay/ 
and "WAO. H each having an associated (although slightly differently named) OLE object. Each of these OLE objects, in 
turn, have other OLE objects related thereto as defined in Fig. 4. Thus, for example, a Parameter object identified by a 
Param Name may be a VariableParameter object a Record Parameter object or an ArrayParameter object. If it is a Var- 
iable Parameter object, it includes collections of "Indexed ItemArray." "Enurn/ "PreEdit," and "PostEdit." allhaving asso- 
30 dated OLE objects: The EnumerationValues object (a collection of the VariableParameter object for variables of the 
enumerated type) has particular enumerated values identif ied by the Enumeration Value object which, in turn, includes 
a collection of Method objects. These Method objects may, for example, include methods of getting or changing enu- 
merated values of a VariableParameter object. 

[0083] The property, data, and methods stored in, or associated with, all of the OLE objects within Fig. 4, except for 
35 the DatabaseParameters and DatabaseParameter objects, represent information which is available from or through the 
use of DD's or a device conforming to a DDL The data and method of the DatabaseParameters objects and Data- 
baseParameter objects are stored in a database. 

[0084] As with Fig. 3. any OLE object in Fig. 4 can be uniquely identified by a moniker developed by tracing a path 
from the Root object of Fig. 3 down to the particular OLE object of interest Thus, for example, the moniker for a pre- 

40 edit Method block could be constructed by adding onto the end of the moniker for any Block object of Fig. 3. which is 
also represented by the Block object of Fig. 4, the expression !param! Param Name lPreEditl Index. 
[0085] Once a moniker is established for a particular object within the hierarchy of Figs. 3 and 4 and stored in the 
memory associated with the server network 66, the DCI 60 and the server network 66 can, thereafter, operate on and 
access that OLE object using a shorter unique "handle* generated by the server network 66. The handle may, for exam- 

45 pie, comprise a unique number identifying an OLE object which has been stored in the memory of the server network 
66. _ 

[0086] In essence, with a unique moniker or the handle, any OLE object identified by the hierarchy of Figs. 3 and 4 
can be immediately accessed by the DCI 60 or the server network 66 and the methods within that OLE object can be 
invoked in order to accomplish communication with the DDS, a database, a smart device, or other OLE objects as nec- 

so essary. Thus, for example, the software routine within the server 68 which accesses the DDS 72 to retrieve a particular 
parameter value from a particular device can be initiated when a call to the propier VariableParameter object is initiated 
by the DCI 60 using a command which tells the OLE VariableParameter object to read a parameter value. 
[0087] As is evident, the server network 66 communicates with the database 40, the DDS 72 s and the on-line devices 
transparently to the DCI 60 and the current application 56, because the server network automatically accesses the 

55 interrelationships between the OLE objects identified by the lower hierarchy of Fig. 4 to determine which set of routines 
to implement in order to obtain new information requested by an OLE object or a DDS. 

[0088] It should be noted that, for any OLE object of Figs. 3 and 4 to be accessed, the OLE objects above that OLE 
object in at least one path between that OLE object and the Root Object Fig. 3 must be stored in the server network 
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memory. Thus, for example, when accessing a VariableParameter object of a parameter for a block, the Parameter 
object and the Block object associated with that parameter and that block will also be stored in the server network mem- 
ory. The Device object, the DevicelD object and the Root object may also be stored in the server network memory. With- 
out these higher level objects, the server network 66 can not access enough information to determine how to locate and 

5 retrieve the data of the VariableParameter object. 

[0089] In a typical situation, the DCI 60 sends a command to get a value from an OLE object, for example, the Han- 
dling property of a VariableParameter object for a particular block of a particular device using a moniker or a handle 
which has been provided for that VariableParameter object. If the identified OLE object has not yet been stored in the 
memory of the server network 66, the server network 66 uses pre-written routines and the methods of the one or more 

io OLE objects above that VariableParameter object to retrieve this data from, for example, one of the DDS 72, the smart 
device itself, or the database 40. The server network 66 then stores this data in a server memory. If needed the server 
network 66 first stores for example, the Root object, the DevicelD object, the Device object the Block object, and the 
Parameters object, in memory. 

[0090] Next, the server uses the methods of the VariableParmeter object and pre-written routines associated there- 
is with to access the DDS 72 (because that is where the Handling information of a variable parameter of a block is 
located). If, as in this instance, the value of the Handling property of the variable parameter depends on the mode 
parameter to which the smart device is currently set, the DDS returns a message to the server 68 telling the server 68 
that the DDS needs the mode parameter information pertaining to the device or block which contains that variable. At 
this point, the server 68 locates the Device object related to the VaribleParameter object to determine how to commu- 
te nicate with the device, i.e., where the device is located in the system and how to interact with that device. The server 
66 then uses a prewritten routine for communicating with the device associated with the Device object to instruct the 
smart device communication interface 74 to retrieve the mode parameter of the device. When the smart device com- 
munication interface 74 returns the mode parameter value to the server 68. the server 68 provides this information to 
the DDS 72 which, thereafter, computes and returns the Handling property to the server 66 which then forwards this 
25 information to the OLE VariableParameter object and. thereby to the DCI 60 (because changes in OLE objects result in 
messages being sent to the host. i.e.. the DCI 60 in this case). Thus, to the DCI 60. it merely appears that a request for 
a read of the Handling property of a parameter was sent to an OLE object and that a message was returned with the 
Handling property. The communication with the DDS and between OLE objects was accomplished automatically by the 
server transparently to the current application 56. and the application did not need to know any specifics regarding the 
30 type of device was accessed, the DD or DDL associated with that device, etc. Thus, using the interface defined above, 
an application can communicate with a number of different smart devices following the same or different DDL protocols 
without the need to consider any of the specifics of the DDS. DDL or DD which must be used to implement that com- 
munication. 

[0091 ] As will be apparent to those skilled in the art. the DCI 60 may thereby operate to communicate with and retrieve 
35 information from the OLE hierarchy represented by Figs. 3 and 4 by performing relatively simple routines which, for 
example. (1) create an object hierarchy and associate it with the server network 66. (2) traverse the object hierarchy to 
explore the objects below a specified object, (3) implement standard OLE methods like Item, which traverses a specific 
path from one object to another, and NewEnum. which creates an interface to enumerate objects one level below, (4) 
implement methods related to Block objects which may include methods related to DDL operations, (5) read and write 
40 Root and Device object properties, (6) initiate and control non-blocking read and write requests from OLE objects. (7) 
retrieve results from blocking reads and writes. (8) control changes to the database 40. and (9) control the creation and 
maintenance of an event log that includes information pertaining to, for example, user changes to the system including 
change times, identification of the persons and the computers which made the changes, etc. 

[0092] As a result, an application for the FMS system 10 does not have to be specifically programmed to interface 
45 with a DDS. database or smart devices which, in turn, allows an application developer to be much less knowledgeable 
with respect to DDL formats, DD's and smart device communications. 

[0093] It will be noted that, using the hierarchy of Figs. 3 and 4 as described above, any application implemented by 
the FMS system 10 can interface with FMS devices using, for example, any OLE -compatible programming environment 
to gain access to the (Unknown and IDispatch interfaces associated with each object in the hierarchy. It is considered 

so that Visual Basic programs and C++ programs are well-suited to use the above-defined OLE hierarchy. 

[0094] Furthermore, although the hierarchy of Figs. 3 and 4 is specifically related to the Fieldbus DDL and to the 
HART DDL, which is very similar to the Fieldbus DDL, it is considered that this or a similar hierarchy can be made for 
other DDL's associated with other smart devices including, for example, Mbdbus smart devices in accordance with the 
present invention. Furthermore, it is considered that the hierarchy of Figs. 3 and 4 can be implemented by other object- 

55 oriented programming protocols and even by non-object oriented programming protocols. 

[0095] As illustrated in Fig. 5, the FMS database 40 (Figs. 1 and 2) contains a transaction database 200 which the 
FMS system 10 uses to store data representing changes made to parameters of the various blocks corresponding to 
devices 16. 18. 20. 22 in the process 12. Specifically, the transaction database 200 is adapted for storing a transaction 
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record 202 corresponding to each parameter change of which the FMS system 10 is or becomes aware. Each transac- 
tion record 202 includes a number of fields 204-213. Each field 204-213, in turn, stores a piece of information relating 
to the "transaction" (i.e., the change in the value of a parameter) which corresponds to the transaction record 202. 
[0096] The fields 204-213 of the records 202 described herein, are identified as BlockKey, TimeKey. ParamName, 

5 ParamKind, ValueMpde, ParamDataType. ParamSize, ParamData, Archived, and Expected. However, the particular 
contents of the transaction records 202 in the transaction database 200 described herein are only exemplary. In accord- 
ance with the present invention, the records 202 of the transaction database 200 can be adapted to contain any other 
necessary or desired information relating to the stored transactions, or other information, if desired. 
[0097] The meaning of each of the particular fields 204-213 is now described in detail in relation to an exemplary 

10 change or transaction comprising the assignment of a particular value (V) to a particular parameter (P) of a particular 
block (B) at a particular time (T). The BlockKey field 204 contains the identifying number of the block to which the 
change applies, whether the change is a past, present, or future change. The identifying number stored in the BlockKey 
field 204 is a unique number which the FMS system 10 assigns to the block B and uses to uniquely identify the block 
B. The value of BlockKey for a particular block, is arbitrary. However, the FMS system 10 must maintain an index (such 

is as in the FMS database 40) of the BlockKeys assigned to all blocks. 

[0098] The TimeKey field 205 stores a number, or a collection of numbers, representing the particular time T when 
the change represented by the transaction record 202 is made. For example, the TimeKey could be an actual calendar 
date and time, expressed with as much precision as is needed (i.e., seconds, milliseconds, etc.), or can be a number 
derived from that information, such as the number of seconds or milliseconds that have elapsed since a particular ref- 

zo erence date and time (e.g., since January 1, 1980, at 12:00 a.m.). For convenience, the TimeKey for a change could 
further be expressed in two fields, one containing the date of the change, and the other containing the time of the 
change. Here, too, the time field could be represented either as an actual time or as a number of seconds (or millisec- 
onds, etc.) elapsed since a reference time. 

[0099] The ParamName field 206 contains the name of the particular parameter P of the particular block B to which 
25 the change stored by the transaction record 202 relates. The names stored in the ParamName fields 206 of transaction 
records 202 are the actual names of parameters used in the OLE parameter objects of the block B, as described above. 
Conveniently, these names also correspond with parameter names found in DDLs. 

[0100] The ParamKind field 207 contains a single alphabetic character corresponding to the kind of the parameter ( P. 
In particular, if the parameter P is an "actual" or "real" parameter, (i.e., one which affects and/or changes the behavior 

30 of a block), then the ParamKind field 207 contains the value "P." ft, instead, the parameter P is a parameter stored in the 
database 40 (Fig. 1 ). then the ParamKind field 207 contains the value "D." The latter type of parameter is stored only in 
the database 40 and not in a device. Additional designations of kinds of parameters can also be provided. (e. g., for user- 
defined parameters or for parameters which contain information about a block but do not affect the block). 
[0101] The ValueMode field 208 contains an alphabetic character indicating whether the value "V" of the parameter 

35 "P" is part of a "real" state of the device corresponding to the block B, or whether it is, instead, part of a "future" state of 
that device. Specifically, the ValueMode field 208 contains the value "H" if the transaction record 202 represents part of 
a real state (i.e., if the record 202 represents a past or present change to the block B). On the other hand, the Value- 
Mode field 208 contains the value "P if the transaction record 202 represents part of a future state (i.e., if the transac- 
tion record 202 represents a change to be made to the block B at an unspecified time in the future). 

40 [0102] The ParamDataType field 209 contains a number corresponding to the type of the data or value "D" stored in 
the parameter P (e.g., 1=string, 2=integer, 3=long-inte ger, 4 ^unsigned long-integer. 5=floating-point, 6-double-preci- 
sion, 7=binary, etc.). The numbers corresponding to the various available data types can be arbitrarily assigned by the 
FMS system 10, but the FMS system 10 must keep track of those assignments. 

[0103] The ParamData Size field 210 contains a number corresponding to the size of the data D stored in the param- 
45 eter P. The value stored in the ParamDataSize field 210 is the number of bytes used to store the data D representing 
the value of the parameter P. 

[0104] The ParamData field 21 1 in a transaction record 202 stores the actual data or value D assigned to the param- 
eter P by the change represented by the transaction record 202. 

[01 05] The Archived field 212 is an optional field which stores an indication of whether the contents of the associated 
so transaction record 202 have already been archived or stored to a backup storage medium. The Archived field serves to 
minimize the time required to complete a backup of the database 200 by identifying those transaction records 202 which 
have already been archived, so that those archived transaction records 202 can be skipped during subsequent archiv- 
ing procedures. The Archived field also provides a safeguard against inadvertent and/or undesired deletion (e.g., by 
housekeeping or utility software) of transaction records 202 which have not yet been archived. The Archived field 212 
55 of a transaction record 202 contains a one or "true" value if the transaction record 202 has already been archived, and 
contains a zero or "false" value otherwise. 

[0106] The Expected field 213 contains an indication of whether the change or transaction represented by the trans- 
action record 202 was identified by the FMS system 10 that made the change as an "expected" change or an "unex- 
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pected" change. As described in detail below, an FMS system 1 0 can use the transaction records 202 of the transaction 
database 200 of the present invention to reconstruct, for any particular time, an expected state of any block of any 
device in the process 12. An "expected" state for a device is the state that an FMS system 10 believes to be the state 
of the device, based on the transaction history stored in the transaction database 200 of the FMS system 10. At any 
given time, however, an FMS system 10 may "expect" a state for a device which is not identical to the actual state of the 
device. For example, a second FMS system 10, or a hand-held communicator 46, may have changed the state of the 
device but not yet informed the f irst FMS system 1 0 that the change was made. 

[0107] Before an FMS system 10 (or a hand-held communicator) makes a change to a device (e.g., the device con- 
taining the block B). the FMS system 10 determines whether the device is in the state that the FMS system 10 "expects" 
or some other "unexpected" state. If the device is in the state expected by the FMS system 10, then the FMS system 
10 makes the change, and stores a one (or other suitable "true" value) in the Expected field 213 of the transaction 
record 202 corresponding to the change (indicating that the change was expected). H, on the other hand, the FMS sys- 
tem 1 0 finds the device to be in a state other than the state in which the FMS system 1 0 expected the device to be, then 
the FMS system 10 knows that a change has been made which was not reconciled intdlhe transaction database 200 
of the FMS system 10. (The procedures by which changes are reconciled into an FMS transaction database 200 are 
explained in detail below.) In that case, the FMS system 10 enters a transaction record 202 in its transaction database 
200 which represents the change that would have to have been made to the device in order to change the state of the 
device from the state expected by the FMS system 10 to the actual state in which the FMS system 10 found the device. 
The FMS system 10 also stores a zero (or other suitable "false" value) in the Expected field 213 for the transaction 
record 202 'corresponding to that change, indicating that the change was unexpected. The Expected field 213 is used 
by an FMS system 10 (such as a primary FMS) in reconciling transaction records 202 from secondary FMS's and/or 
hand-held communicators 46 into the primary FMS system 10 as described in more detail below in connection with Fig. 
9 and 10. 

[01 08] The ParamKind field 207, the ValueMode field 208. the ParamDataType field 209. and the ParamDataSize field 
210 of a transaction record 202 are included in the transaction record 202 simply to facilitate processing of the data 
stored in the ParamData field 211 of the transaction record 202. and of the parameter object corresponding to the 
parameter P as a whole. As noted above, any other suitable information, such as the name of the person who made the 
change, the reason why the change was made, or any other information which may be required by standard plant oper- 
ating procedures, regulatory requirements, or user preferences, c?an also be stored in the transaction records 202 of the 
transaction database 200. Alternatively, this additional information can be stored in a second data table similar to the 
transaction database 200, and including transaction-identifying information (e.g., the BlockKey. the TimeKey. and the 
ParamName fields 204. 205, and 206) together with additional fields for the additional information. The FMS system 10 
then accesses the additional information for each change by cross-referencing to the second data table using the trans- 
action-identifying fields in the particular transaction record 202 representing the change in the transaction database 
200. 

[0109] The database functions performed by the FMS system 10 with respect to the transaction database 200 are 
now described in detail. Generally, the FMS system 10 uses the transaction database 200 to maintain historical records 
of changes made to smart field devices, e.g. . devices 1 6. 1 8. 20, 22, in the process 1 2; to store current values of param- 
eters in the various field devices; and to store records of future changes to be made to those devices. Several specific 
functions can be performed by the FMS system 10, with respect to the transaction database 200. 
[01 10] The first function is that when the FMS system 1 0 (sometimes referred to herein as the primary FMS system) 
itself makes a change to a parameter of a device or, more particularly, to a specific block of the device, the FMS system 
10 adds a record 202 to the database 200 providing all of the above-described information in relation to that change. 
The BlockKey assigned by the FMS system 10 to the block in which the change is made is stored in the BlockKey field 
204. The TimeKey corresponding to the time at which the change is made is stored in the TimeKey field 205. The name 
of the parajTieterwhc^e value is chan ged is stored in the ParamName field 206. The kind of that parameter is stored in 
the ParamKind field 207] The mode of the value of the parameter is stored in the ValueMode field 208. The type of the 
data stored by the parameter is stored in the DataType field 209. The size of the data stored by the parameter is stored 
in the ParamDataSize field 210. The new value stored in the parameter is stored in the ParamData field 211. The 
Archived field 212 is set to zero, of course, because the transaction record 202, being new, cannot yet have been 
archived. Lastly, because the FMS system 10 itself made the change to the device, the Expected field 213 is set to one 
which indicates that the change is an expected one: the change clearly is "expected" because the FMS system 10 
authorized and made the change itself 

[01 1 1 ] In many installations, the FMS system 1 0 is not permanently connected to all smart devices in the process 1 2, 
because such permanent connections typically are costly to install even though they provide advantages in terms of 
ease of configuration of the devices by the FMS system 10 to which the devices are permanently connected. A so- 
called transient or temporary connection can be provided between the FMS system 10 and a smart device which is not 
permanently connected to the FMS system 10, so that the FMS system 10 can make a desired change in the smart 
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device. Alternatively, a secondary FMS system 46 can first be connected to the primary FMS system 10 to receive 
instructions as to what change to make, and the secondary FMS system 46 can then be disconnected from the primary 
FMS system 10 and connected instead to the smart device so that the secondary FMS system 46 can make the change 
instructed by the primary FMS system 10. 
5 [01 1 2] When the primary FMS system 1 0 sends instructions to a secondary FMS system 46 for making a change, the 
primary FMS system 10 also sends the -expected" state of the device to the secondary FMS system 46 together with 
instructions for the change to be made {i.e., the name of the parameter that is to be changed, and the new value for 
that parameter). 

[0113] After the secondary FMS system or laptop computer 46 is loaded with change instructions by the primary FMS 
io system, a technician takes the secondary FMS system 46 into the field and connects it to the smart field devices 16, 
18, 20 and/or 22, etc., of the process, to which changes are to be made and performs the following change-making 
operation (Fig. 7). 

[01 1 4] Fig. 7 depicts a flowchart illustrating how an FMS system 1 0 interacts with the transaction database 200 when 
making a change to a smart device 16, 18, 20, or 22 in the process 12. Of course, the FMS system 10 can change a 

is device only if it is coupled to the device, whether electrically or via any other suitable mode of communication. As noted 
above, an FMS system 1 0 can have a permanent connection to a field device or a transient one. A transient connection 
between a secondary FMS system 46 and the FMS system 10 is shown by a dashed line 47 in Fig. 1 t and another such 
connection is shown between a secondary FMS system 46 (which may additionally or alternatively represent a hand- 
held communicator 46) and a field device 20. If an FMS system 10 is permanently connected to a field device, it can 

so make changes to the field device by itself. If the device is not permanently connected to the FMS Gystem 10, the FMS 
system 10 can be used to make a change in the field device in two ways. First, the field device can be transported to 
the site of the FMS system 1 0 and interfaced with the FMS system 10 via a transient connection to a serial-interface or 
other port of the FMS system 10 so that, again, the FMS system 10 can make the change itself. Second, if interfacing 
the device with the FMS system 10 directly is impractical or inconvenient, a secondary FMS system 46 (Fig. 1) can be 

25 transiently connected to, or interfaced with, the FMS system 10 and instructed by the FMS system 10 to make the 
required changes. The secondary FMS system 46 is then disconnected from the FMS system 10 and taken by a field 
operator to each remote field device in which a change is to be made. The operator connects the secondary FMS sys- 
tem 46 to the field device, and the secondary FMS system 46 makes the change just as would the FMS system 10. . 
[0115] Hereinafter, for simplicity, the FMS system 10 and the secondary FMS system 46 are occasionally referred to 

30 as the primary FMS system and the secondary FMS system, respectively. It should be noted that these labels are 
merely arbitrary designations and that the primary and secondary FMS systems can be equivalent in structure and 
function, or the secondary FMS system can have reduced functionality compared to the primary, if desired. 
[01 1 6] The process by which an FMS system (whether primary or secondary) makes one or more changes to one or 
more parameters in a smart field device, such as the HART devices 16, 18, and 20 or the Fieldbus device 22 (Fig. 1), 

35 for example, is now described in detail with reference to Fig. 7. 

[01 1 7] The change-making process begins at a block 220 where the FMS system 1 0 or 46 connects to the smart field 
device to which a change is to be made and retrieves the actual state of that device by obtaining values from the device 
for all of the parameters of the particular block to which the change is to be made. A block 222 then compares the actual 
state of the device to the expected state of the device, which, as described above, was stored in the FMS system 10 

40 before the FMS system 10 was connected to the device. When the primary FMS system 10 instructs a secondary FMS 
system 46 to make a change to a device, the primary FMS system 10 communicates the expected state of that device 
to the secondary FMS system 46. 

[0118] If the block 222 determines that the actual state of the device equals the expected state, then a block 224 
causes the FMS system 10 to apply the next change to the device, and a block 226 adds a record of that change to the 
45 transaction database 200 (Fig. 5). If the block 222 determines that the actual state of the device is not equal to the 
expected state of the device, then, before the block 224 applies the change to the device, a block 228 calculates an 
"unexpected** change and adds a record of the unexpected change to the transaction database 200 so that the trans- 
action database 200 accurately reflects the present state of the device as it exists before the FMS system 10 makes the 
change. 

so [01 1 9] Specifically, the unexpected change is the change that necessarily must have been made (unbeknownst to the 
FMS system 10) to change the state of the device from the state in which the FMS system 10 expected the device to 
be, on the one hand, to the actual state in which the FMS system 10 found the device, on the other hand. After the 
"unexpected** change recor6 is added to the transaction database 200, a block 230 permits the operator of the FMS sys- 
tem 10 to make additional changes to the device and. if any such additional changes are made, the FMS system 10 

55 stores transaction records in its transaction database 200 representing the additional changes. These additional 
changes are identified in the transaction database 200 as "expected" changes. 

[0120] Thereafter, control passes to the block 224 which, as described above, applies the next change to the device. 
Once a record of that change is added to the transaction database 200 of the FMS system 10 by the block 226, a block 
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232 determines whether the FMS system 10 must make any further changes to the device to which it is connected. If 
so, control returns to the block 222 to repeat the foregoing process for the next change; if not, the process of Fig. 7 ends. 
[0121] In addition to instructing a secondary FMS system to make changes, the primary FMS system 10 can down- 
load change instructions to a hand-held, intrinsically safe communicator 46, such as the Model 275-HC HART Cbmmu- 
5 nicator manufactured by Fisher-Rosemount Systems, Inc. Such a hand-held communicator 46 is used by a field 
operator to take change information to a HART field device located in an area remote from the primary FMS system 
and/or in a hazardous area where intrinsically safe instrumentation is required (secondary (laptop) FMS systems are 
unusable in such hazardous areas). The operator can connect the hand-held communicator 46 to the smart HART field 
device to make the changes. 

io [0122] The process by which a change is made to a smart field device using a hand-held communicator 46 (Fig. 1) is 
now described in detail in connection with Fig. 8. 

[0123] First, as shown in Fig. 1 , a hand-held communicator 46 is connected to the FMS system 10, and the FMS sys- 
tem 10 stores a configuration for a particular device in the memory of the hand-held communicator 46, as indicated by 
a block 240 (Fig. 8). Of course, multiple configurations can be stored in the hand-held communicator 46 for multiple 
is devices, if desired. In addition, the hand-held communicator 46 can receive configuration information from a secondary 
FMS system 46 in the same manner as it receives configuration information from the primary FMS system 10 as 
depicted in Fig. 1 . 

[0124] After the hand-held communicator 46 is loaded with configuration information for one or more smart field 
devices 16, 18. 20, 22, the hand-held communicator 46 is connected to one of the smart field devices where the com- 

20 municator 46 applies the new configuration for that device to the device as indicated by a block 242. 

[0125] A configuration includes all of the same information as a change referred to above in connection with the pri- 
mary and secondary FMS systems 1 0 and 46. Further^ a configuration can' include new values for either some (a partial 
configuration) or all (a full configuration) of the parameters of a device. The difference between a configuration and a 
change is simply that a configuration, unlike a change, does not include an indication of a time. The reason for this dif- 

25 ference is that cost constraints on hand-held communicators 46, and the desire that they be very simple to use, prevent 
them from providing a time-keeping function. Hence, the procedure illustrated in Fig. 8 by which a hand-held communi- 
cator 46 makes a change to a device is rather simple compared to the procedure illustrated in Fig. 7 by which an FMS 
system 10 makes such a change. As a result however, the operations that can be performed by a hand-held commu- 
nicator are rather unsophisticated compared to the operations of. "an FMS system 10. 

30 [0126] Optionally, as indicated by a block 244, shown in phantom lines in Fig. 8, the hand-held communicator 46 can 
read back the entire state of the device to which it is connected, and return that state to the primary FMS system 10 (or 
to a secondary FMS system 46). so that the FMS system 10 or 46 can reconcile the new state of the device with the 
transaction database 200 of the FMS system. Typically, a plant might require this procedure as part of a standard oper- 
ating procedure in situations where it is essential to ensure that the changes that an FMS system 10 instructs a hand- 

35 held communicator 46 to make are actually made. Importantly, when an FMS system 10 communicates a configuration 
to a hand-held communicator 46, the FMS system 10 inserts a transaction in its transaction database 200 to reflect the 
change corresponding to the conf iguration. The transaction record is designated as an expected change, because the 
FMS system 10 presumes that the hand-held communicator 46 will in fact make the change. 

[0127] As described above, multiple FMS systems can be interconnected so that data in their respective transaction 
40 databases 200 can be merged to form a consistent global view of the plant serviced by the multiple FMS systems. TTits 
capability facilitates the review of historical information about the operation of a plant, such as by auditors responsible 
for ensuring the compliance of the plant with the regulatory requirements of various governmental agencies as 
described above, and also with the guidelines or rules established by plant safety groups. 

[0128] Fig. 9 depicts a flowchart illustrating a process by which the transaction database 200 of one FMS system 
45 (e.g.. a secondary FMS system 46) can be merged into the transaction database 200 of another FMS system (e.g., a 
primary FMS system 10). As indicated previously herein, any FMS system can serve as a primary or as a secondary, 
but the "primary FMS" designation typically refers to a stationary system; secondary FMS systems typically reside in 
laptop computers which may not always be readily accessible when needed, such as for a compliance audit In the fol- 
lowing description, the labels FMS1 and FMS2 refer to the transaction databases 200 of the primary and secondary 
so FMS systems, respectively. 

[0129] Initially, a block 250 determines whether any unreconciled transaction records are present in the secondary 
FMS system 46. tf not, or when all unreconciled transactions in the secondary FMS system 46 have been reconciled, 
the process of Fig. 9 is finished. H unreconciled transactions remain in the secondary FMS system 46 (i.e.. transaction 
records which have not yet been reconciled into the transaction database 200 of the primary FMS system 10). then a 
55 block 252 loads the next unreconciled transaction record (referred to herein as TR) from the memory of the secondary 
FMS system 46 into the memory of the primary FMS system 10. A block 254 then examines the transaction record TR 
to determine whether the change represented by that transaction record is an expected change. If it is, then a block 256 
determines whether the transaction record TR represents the same change as a change which is already present in the 



17 



EP0 961 184A2 

primary FMS transaction database FMS1 but which is designated as an "unexpected" change in FMS1. If the change 
represented by the transaction record TR does not match an unexpected change in FMS1 , then the transaction record 
TR is inserted in the primary FMS transaction database FMS1 in chronological order, and control returns to the block 
250 to determine whether any further unreconciled transaction records remain in the secondary FMS system 46. If the 
5 change represented by the transaction record TR does match an unexpected change present in the transaction data- 
base FMS1, as determined by the block 256, then a block 260 replaces that unexpected change with the transaction 
record TR (which is an expected change), and control then returns to the block 250. 

[0130] If. on the other hand, the block 254 determines that the transaction record TR represents a change which is 
unexpected, then control passes to a block 262 which determines whether the primary FMS transaction database 

ro FMS1 contains a transaction record representing the assignment of the same value to the same parameter as the 
change represented by the transaction record TR, and which transaction record bears a TimeKey (field 205, Fig. 6) 
which approximates the TimeKey of the transaction record TR to within some predetermined acceptable temporal tol- 
erance. If no such transaction record is present in FMS1 f then a block 264 appends thetransaction record TR at the 
end of the primary FMS transaction database FMS1 and designates the change representeclby that transaction record 

is as "unexpected" by setting the Expected field 213 of the record 202 corresponding to that change in the FMS transac- 
tion database FMS1 accordingly. Thereafter, control returns to the block 250 to check for more unreconciled transaction 
records 202 in the secondary FMS system 46. If the block 262 determines that a change resembling the unexpected 
change represented by the transaction record TR does already appear in the primary FMS transaction database FMS1 , 
then a block 266 discards the transaction record TR, inasmuch as the actual change corresponding to the unexpected 

20 transaction record TR is already represented by a transaction record 202 in the transaction database FMS1 . Again, 
control thereafter returns to the block 250 to check for more unreconciled transactions in the secondary FMS system 
46. 

[0131] Several examples of the use of the FMS transaction database 200 are described below in detail in connection 
with the accompanying tables. In the first example, a primary FMS system 1 0 (P_FMS) instructs a secondary FMS sys- 
25 tern 46 (S_FMS) to make a future change CF (i.e., a change for which no time is yet specified) to a particular smart 
field device (refer to the table entitled "Example 1"). This example illustrates what happens to the primary and second- 
ary FMS systems and to the device as this instruction is carried out and the result is reported back to the primary FMS 
system 10 by the secondary FMS system 46. , ' . 
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Example 1 




Occurrence 


Time 


PJFMS 


S_FMS 


Device 


35 


Primary FMS database (P_FMS) and sec- 
ondary FMS database (S_FMS) accurately 
reflect actual state of Device. 




S(i) 


, S(i) 


S(i) 


40 


Primary FMS instructs secondary FMS to 
make change CF to Device. 


i+1 


S(i) 


S(i); also holds record of change CF 


S(Q 


45 


Secondary FMS attempts to make change 
C(i+1) to Device. Prior actual state S(i) of 
Device matches state S(i) expected by 
S_FMS so change C(i+1) is made and is 
recorded in S_FMS designated as 
"expected." Device is now in state S(i+1). 


i+2 


S(i) 


S(>+1) 


S(i+1) 


so 


Secondary FMS reports change C(k1) to 
primary FMS, which reconciles that change 
into P_FMS. 


i+3 


S(i+1) 


S(i+1) 


S(i+1) 



[0132] The first row of the foregoing table describes the primary and secondary FMS systems in the field device at 
some arbitrary time i. At time i, the actual state of the device is S(i), and this state is accurately reflected in the transac- 
tion databases 200 of the primary FMS system 10 and the secondary FMS system 46. 
55 [0133] At a later time the primary FMS system 10 instructs the secondary FMS system 46 to make a future 
change to the device. Therefore, at this time, the device remains in the state S(i). Further, the primary and secondary 
FMS transaction databases P_FMS and S_FMS continue to accurately reflect that the actual state of the device is S(i), 
but the transaction database 200 of the secondary FMS system 46 now holds a transaction record 202 representing the 
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future change CF. 

[0134] At yet a later time, the secondary FMS system 46 is connected to the device and attempts to make the future 
change, designated C(i+1 ), to the device. Because the secondary FMS system 46 detects that the prior actual state S(i) 
of the device matches the state S(i) that the secondary FMS system 46 expected for the device, the secondary FMS 

5 system 46 makes the change to the device and records in its transaction database S_FMS a transaction record 202 
corresponding to the change. Because the change was made to the device, the device is now in state S(i+1), and 
because the transaction record for that change (which, incidentally, is designated as an expected change in the trans- 
action database 200), the expected state of the device reflected in the transaction database 200 of the secondary FMS 
system 46 is also updated to S(i+1). However, because the primary FMS system 10 has not yet been informed that the 

io secondary FMS 46 has successfully made the future change CF, the primary FMS system 10 maintains S(i) as the 
expected state for the device. 

[0135] When the secondary FMS system 46 connects to the primary FMS system 10 at time i+3 and communicates 
the transaction record corresponding to the change C(i+1) to the primary FMS system 10, the primary FMS system 10 
reconciles that transaction record into its primary FMS transaction database 200 as described above in connection with 

is the process of Fig. 9. Specifically, because the incoming transaction record was designated as an expected change, 
and because the change had not yet been entered in the primary FMS transaction database 200 as an unexpected 
change (presuming that it really had not been), the transaction record for the change C(i+1) is entered into the primary 
FMS transaction database 200 in chronological order by the block 258 (Fig. 9) such that the expected state of the device 
as now reflected by the transaction database 200 of the primary FMS system 10 accurately reflects the actual state of 

20 the device, namely S(i+1). 

[0136] If, instead, when the transaction record representing the change C(i+1) was reconciled with the primary FMS 
transaction database 200, a matching unexpected change was determined to be present in the primary FMS transac- 
tion database 200. then the transaction record for the expected change C(i+1) would have been inserted in place of the 
transaction record 202 for the corresponding unexpected change in the primary FMS transaction database 200. 

25 [0137] Another example, which illustrates the reconciliation of a transaction record 202 representing an "unexpected" 
change into the primary FMS transaction database 200 is now described in detail with reference to the following table, 
entitled "Example 2/ 
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Example 2 






Occurrence 


Time 


P_FMS 


S_FMS1 


S_FMS2 


Device 


35 
AO 


Primary FMS database 
(P_FMS) and second- 
ary FMS databases 
(S_FMS1 and 
S_FMS2) accurately 
reflect actual state of 
Device. 




S(i) 


S(i) 


S(i) 


S(i) 


45 


Secondary FMS1 
instructed to make 
change C(i+1) to 
Device. Secondary 
FMS2 instructed to 
make future change CF 
to Device. 


k1 


S(i) 


S(i); also holds record 
of change C(i+1) 


S(i): also holds record 
of future change CF 


S(i) 


50 


Secondary FMS1 
makes change C(i+1) 
to Device. Secondary 
FMS2 has not yet 
made future change 
CF. 


i+2 


S(i) 


S(i+1) 


S(i); also holds record 
of future change CF 


Sfi+1) 



55 



19 
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(continued) 





Example 2 




Occurrence 


Time 


P_FMS 


S_FMS1 


S_FMS2 


Device 


5 

TO 

75 


Secondary FMS2 
attempts to make 
future change CF and 
detects unexpected 
state S(1+1) (resulting 
from change C(i+1 ) 
made by secondary 
FMS1). Secondary 
FMS2 then records a 
corresDondina unex- 
pected change CU in 
S_FMS2 and makes 
the change CF to the 
Device. 


i+3 


S(i) 


S(i+1) 


S(i+2); also holds 
record of unexpected 
change CU 


S(i+2) 


SO 


Secondary FMS2 
reports unexpected 
change CU and author- 
ized change C(i+2) to 
primary FMS. 


i+4 


S(i+2); CU added to 
P_FMS database 


S(i+1) 


S(i+2) 


S(i+2) 


25 


Secondary FMSt 
reports change C(i+1) 
to primary FMS, which 
reconciles that change 
into P_FMS database. 


i+5 


S(i+2), CU replaced 
byC(i+1)inP_FMS 
database 


S(i+2) 


S(i+2) 


S(i+2) 
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[0138] In this example, a primary FMS system 10 and two secondary FMS systems 46 accurately reflect the actual 
state S(i) of a device at an initial time L 

[0139] At a later time i+1, the primary FMS system 10 instructs the first secondary FMS (FMS1) to make a change 

35 C(i+1) to a device. Also at that time, the primary FMS system 1 0 instructs the second secondary FMS (FMS2) to make 
a future change CF to the same device. Therefore, at time i+1 , the transaction databases 200 of the primary FMS sys- 
tem and the first and second secondary FMS systems accurately reflect the actual state S(i+1) of the device. In addi- 
tion, a record of the change C(i+1) is stored in the first secondary FMS system 46, and a record of the future change 
CF is stored in the second secondary FMS system 46. 

40 [0140] At a later time i+2, FMSl makes the change C(i+1 ) to the device according to the procedure described above 
in connection with Fig. 7. Consequently, at this time, FMS1 accurately reflects the actual state S(i+1) in its transaction 
database 200. while the primary FMS PFMS and the second secondary FMS FMS2 continue to reflect the prior state 
S(i) of the device in their respective transaction databases 200. Also, FMS2 still holds a transaction record for the future 
change CF which has not yet been made. 

45 [0141] At a later time i+3, FMS2 attempts to make the future change CF to the device and detects that the device is 
-in-an unexpected- state S(i+1) (/.e., a state other than the state S(i) which the transaction database 200 of the FMS2 
reflects). FMS2 therefore computes the unexpected change CU that must have been made to change the device state 
from S(i) (expected by FMS2) to S(i+1) (the actual state of the device). FMS2 then records a transaction record corre- 
sponding to the unexpected change CU in its transaction database 200 and then makes the future change CF to the 

so device and records a transaction record corresponding to the change CF together with a current TimeKey in the trans- 
action database 200 of FMS2. Therefore, the transaction database 200 of FMS2 now accurately reflects the current 
state S(i+2) of the device, and the transaction database 200 of FMS2 further includes a record of the unexpected 
change CU which FMS2 recognized to have been made to the device. 

[0142] Later still, at time i+4. the secondary FMS system FMS2 is connected to the primary FMS system 10 and 
55 reports the unexpected change CU and the now-made, authorized change C(i+2) to the primary FMS system 10. The 
transaction records for these two changes are then reconciled by the primary FMS system 10 into its transaction data- 
base 200 according to the procedure of Fig. 9. so that the transaction database 200 of the primary FMS system 10 
accurately reflects the actual state S(i+2) of the device and includes transaction records corresponding to the changes 
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CU and C(i+2). The primary FMS FMSl slill reflects that it expects a state of S(i+1) for the device, while the secondary 
FMS FMS2 accurately reflects the actual state S(i+2) of the device. 

[0143] At yet a later time i+5, FMS1 is connected to the primary FMS system 10 and reports change C(i+1) thereto. 
The primary FMS system 10 reconciles the transaction record for change C(i+1) into its transaction database 200 and 

5 finds that C(i+1) matches the unexpected change CU entered into the transaction database 200 of the primary FMS 
system 10 during time h-4. Therefore, in accordance with the block 260 (Fig. 9), the transaction record tor the change 
C(i+1) replaces the transaction record for the unexpected change CU in the transaction database 200 of the primary 
FMS system 10. Therefore, at this time, all outstanding transaction records 202 have been reconciled into the primary 
FMS transaction database 200, which now accurately reflects the actual current state of the device S(i+2) and also, very 

io importantly, a complete historical accounting of the configuration history of the device {i.e.. a device configuration his- 
tory). 

[0144] The functionality of the interface block 58 will now be described in more detail. As noted above, during opera- 
tion, the current application 56 calls the interface Bock 58 to initialize one or more specific controls which, thereafter, 
automatically handle all operations associated with interfacing between the Windows operating system 46. the smart 
is devices within the process 1 2 and/or the FMS database 40 with respect to a device, a block, or a parameter associated 
with the process 12. The interface block 58 may also change the Time property of the Root object stored in the memory 
of the server network 66 to control displays in an advantageous manner. 

[0145] Each control of the interface block 58 displays and updates information pertaining to a device, a block, a 
parameter, ( or a time on the display 30; and communicates with the smart devices, the database 40, and the server net- 
20 work 66 in response to user or application inputs to retrieve data from, or write data to, the DDS 72, the smart devices, 
the database 40, or the Root object in the server network 66. without further involvement of the current application 56. 
Importantly, once established, a control generally appears to run independently of the current application 56 and of 
other controls which may have been established. 

[0146] As illustrated in Fig. 11, the interface block 58 includes a master control routine 300 which can be used to 
25 implement control functions, including control functions relating to a device, a block, or a parameter associated with the 
process 12. The interface block 58 also includes a master timeline control routine 301 which can be used to implement 
control functions such as reading and writing times from the Root object and changing time values from the database 
40. 

[0147] When the current application 56 calls the interlace block 58 to implement a device, block, parameter or timeline 
30 control, one of the master control routines 300 or 301 is, in effect, copied and converted into a specific control routine 
or control. Such specific controls are illustrated in Fig. 1 1 as a device control 302, a block control 304, a parametercon- 
trol 306 and a timeline control 308. The specific controls 302. 304. 306, 308 thereafter automatically handle functions 
related to communication between the Windows operating system 46, the current application 56, the database 40 
(through the DCI 60), the DDS 72 (through the DCI 60), and the on-line smart devices (through the DCI 60) as those 
35 communications relate to the specific devices, blocks, parameters, or timelines for which the controls are created. Once 
established, each of the controls 302, 304, 306. 308 opera te, continuously and independently of the other controls and 
the current application 56. Any number of the same and/or different control types can be implemented to operate at the 
same time. 

[0148] While Fig. 1 1 illustrates the controls 302, 304, 306, 308 as separate routines which are copies of one of the 
40 master control routines 300 or 301, controls 302, 304, 306. 308 can also contain the data necessary to implement a 

particular device, block, parameter, or timeline control using one of the master control routines 300 or 301 . 

[0149] Fig. 12 generally illustrates the steps that should be performed by. for example, the current application 56 to 

initialize a control, including any of the controls illustrated in Fig. 11. A block 310 defines the type of the control, for 

example, a device, a block, a parameter, or a timeline control, by providing the interface block 58 with a unique moniker 
45 pointing to the OLE object within the hierarchy of Figs. 3 and 4 with which the control is associated. Because, concep- 
- tually. an instantiation of the hierarchy of Figs. 3 and 4 exists for each time availabjeto the FMS_appljcation, the timeline 

control specifies the Root object of a particular hierarchy by specifying, for example, the time and view of the Root object 

with which the control is associated. 

[0150] A block 31 1 defines the user interface attributes including, for example, the fonts, sizes, etc., of display char- 
so acters. the style in which the information is to be displayed, the display screen location at which the control information 
is to be displayed, the initial window size of the control display if the size of a control display is capable of being changed 
by the user, and the so-called "visibility" of the control. Control visibility defines whether the control will actually be dis- 
played or be visible on the screen. While an invisible control sti!! operates to retrieve data from its associated OLE object 
and may provide such information to the current application 56. the user interface operations of that control are simply 
55 disabled. 

[0151] A block 312 defines the refresh rate of the control {i.e., the rate at which the control will receive information 
from its associated OLE object in a periodic read). In effect the block 312 connects the control to a particular Root 
object of the hierarchy in Figs. 3 and 4, and the Root object defines the rate at which the OLE object will refresh data in 
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response to a periodic read. 

[0152] Fig. 13, illustrates the general operation of a control routine which can be used for the device control, the block 
control, the parameter control and the timeline control of Fig. 1 1 . A block 313 connects to or establishes a connection 
to the proper OLE object as defined by the hierarchy of Figs. 3 and 4 and the moniker provided by the current applica- 
5 tion 56. Specifically, the control sends a command through the DCI 60 to the server network 66 to read information, for 
example, the properties, of the OLE object associated with the control. Preferably, this command is a periodic read 
which tells the OLE object, such as a device, a block or a parameter object, to periodically send the requested data to 
the control. 

[0153] In response to the read, the server network 66 establishes a connection to the OLE object by retrieving the 
70 data thereof from the QDS 72, the smart devices and/or the database 40, and stores that data as the OLE object in a 
server network memory. To perform this read function, however, the server network 66 must also store in its memory 
the data pertaining to the Device and/or Block objects above the requested OLE object as defined by the hierarchy of 
Figs. 3 and 4. When stored in the server memory, the requested OLE object data is sent to the DCI 60 and then to the 
interface block 58 where this data may be stored in a memory or control cache associated with the interface block 58. 
75 [01 54] A block 314 then establishes or initializes a user interface screen on the display 30 for the particular control as 
defined by the user interface attributes provided to the control by the block 31 1 of Fig. 12. The display attributes may be 
configured to display control information in any desired manner using standard Windows calls and Windows formats. 
An exemplary screen for each of the device, parameter, block, and timeline controls is illustrated in Figs. 20-22. 
[0155] Next, a block 315 checks to see H any messages have been received from the application, the user interface 
20 via the Windows operating system 46, or an OLE block through the DCI 60. If no such messages have been received, 
the block 315 continually re-checks for such messages. When the block 315 receives a message, control is transferred 
as indicated by the identifiers labeled 1 , 2, and 3. 

[0156] Fig. 14 illustrates the operation of a control in response to a message from the current application 56. A block 
316 interprets the message which can be of three general types, including a read OLE object data message, a change 

25 Parameter object value, or a Root object value message and a change user interface message. In response to a read 
OLE object data message, a block 318 reads the requested data from the referenced OLE object of Figs. 3 and 4. For 
example, a device control may read the DevicelD property or the Tag" collection of a Device object white a block control 
may read the Name property or the "Param" collection of a Block object A parameter control might read parameter 
properties such as the value or name of a VariabteParameter object. A timeline control can read Root object properties 

30 and may obtain a list of times for which Root objects exist in the past from the database 40. Thereafter, the block 318 
returns control to the block 315. 

[0157] In response to a change-parameter or root-value message, a block 320 implements a change to the referenced 
parameter object, for example, the VariableParameter object, Record Parameter object, or ArrayParameter object of Fig. 
4 and returns control to the block 315. In response to a change-user-interface message, a block 322 implements a 

35 change of the user interface and returns control to the block 315. , 

[0158] Fig. 15 illustrates a routine 324 which is implemented by a control during a read OLE object data procedure. 
Specifically, a block 326 sends a message through the DCI 60 to the OLE object associated with the control to retrieve 
data from that OLE object. Thereafter, a block 328 determines what type of read message was received. If a non-block- 
ing, non-periodic or a non-blocking, periodic read message was received, the block 328 returns control to the block from 

40 which the routine 324 was called. A non-blocking read refers to one in which the control sends a read message to the 
OLE object associated with the control and does not wait for a response from the OLE object before continuing with 
other functions. A non-periodic read is a request for a single, one-time read from the OLE object associated with the 
control. A periodic read instructs the OLE object to periodically notify the control of changes which occur to data within 
the OLE object at a rate defined within the Root object associated with that OLE object. 

45 [0159] If, however, the read was a blocking read, which is always a non-periodic read, a block 330 waits for the return 
data requested from the OLE object. Next, a block 332 stores the received OLE object data in the control cache. If nec- 
essary, a block 334 changes the user interface by calling a user interface change routine described hereinafter to reflect 
the new data obtained by the read. A block 336 notifies the current application 56 if the application has identified that it 
wants to receive messages or data changes from OLE object data reads during, for example, initialization of the control. 

so Thereafter, control is returned to whatever block called the routine 324. 

[01 60] Fig. 1 6 illustrates a routine 338 which is implemented by a control during a change of a parameter or root value 
of an OLE parameter object (such as the VaribleParameter object) or a Root object. A block 340 determines whether 
the parameter or root value indicated to be changed is writable. In essence, the block 340 sends a message to read the 
handling properties of the OLE object and determines whether the parameter value is writable. If the block 340 deter- 

55 mines that the parameter or root data value is not writable, a block 342 notifies the user or the current application 56 
that the parameter or root value is not writable, such as by calling the change-user interface routine described below. 
Thereafter, control is returned to the block from which the routine 338 was called. 

[0161] If, on the other hand, the block 340 determines that the parameter or root value is writable, a block 344 deter- 



22 



BNSDOCID: <EP 0961 IftdAP I » 



EP0 961 184 A2 



mines if the new parameter value (or root value) is an accepted value. To perform this function, the block 344 reads, for 
example, the value characteristics of the parameter-object associated with the control such as the minimum value, the 
maximum value and the type of value accepted which may be, for example, a variable, an enumerated set, etc. If, there- 
after, the block 344 determines that the new value is out of range or of the wrong type, a block 346 may send a message 
5 to the application and/or may change the user display to indicate that an unacceptable value has been entered. There- 
after, control is returned to the block which called the routine 338. 

[0162] If the block 344 determines that the new value is an accepted value for a parameter or a root object, a block 
348 sends a change message to the correct OLE parameter or root object through the DCI 60. The new value is then 
changed in the OLE object which, of course, may cause a corresponding change in a smart device or in the database 
10 40. 

[0163] A block 350 waits for a return message and a block 352 decodes the return message to determine if the write 
was successful. If the write was successful, a block 354 may. indicate to the application and/or to the user via the user 
interface that the change was made {e.g.. by changing the color of the background of the data on the screen). 
[0164] If the block 352 determines that the write was not successful, a block 356 indicates to the application and/or 
is to the user via the user interface that the change was not made (e.g., by changing the data on the screen to its original 
state). Incidentally, the response codes associated with an OLE object are always available to an application so that the 
reason for the rejection can be determined and/or displayed to the user. 

[0165] H the block 352 determines that the change was made but that a write condition exists, a block 358 retrieves 
a response code from the OLE object by specifically initiating a proper read from the OLE object. A block 360 then indi- 

20 cates to the application, and/or to the user if desired, that the change was made but that a write condition exists. The 
block 360 may also indicate the type of condition that exists (e.g., that the OLE object property was set to the nearest 
available possible value). Each of the blocks 354, 356, and 360 returns control to the block which called the routine 338. 
[01 66] Fig. 17 illustrates a routine 362 which is implemented by a control to change the user interface display. A block 
364 changes the display interface attributes in conjunction with new attributes provided by the current application 56, or 

25 in accordance with a set of attributes previously defined by the control for the condition which now exists. These previ- 
ously defined attributes may be stored in a memory associated with the control, such as the control cache. A block 366 
refreshes the user display using the new user display attributes and the data in the control cache which is to be dis- 
, played. Thereafter, control returns to the block from which the routine 362 was called. 

[0167] Fig. 18 illustrates the operation of a control in response to a message from the user interface. A block 370 
30 checks to determine if the user action is meaningful."The block 370 may, for example, determine if the user clicked the 
proper button of the mouse or if the pointer (i.e., the cursor or arrow) was located within an area of the control display 
where the control recognizes the user's actions as requests for action. If the user action is not meaningful, a block 372 
simply ignores the user action or gives some indication that the action has been ignored (e.g., refreshing the user dis- 
play with the same display interface attributes) . Thereafter, control is returned to the block 315. 
35 [01 68] On the other hand, if the user action is meaningful, a block 374 interprets the message from the user interface. 
If the message from the user interface indicates that the user would like to change a parameter value or a root value, a 
block 376 calls the change-parameter/root-value routine 338 and then returns control to the block 315. If desired the 
block 376 may also change the user interface, for example, to implement a color change to the background field sur- 
rounding the data to be written. Upon receiving an indication of a successful write, the block 376 may also return the 
40 background color to its original state to indicate that the value has been written (if the routine 338 has not already done 
so). 

[0169] If, on the other hand, the block 374 determines that the user is requesting a change in the user interface, a 
block 378 calls the change-user-interface routine 362 and returns control to the block 315. 

[01 70] Fig. 1 9 illustrates the operation of a control in response to a message from the DCI 60, i.e., from an OLE object 
45 within the hierarchy of Figs. 3 and 4. A block 380 first determines if the message from the DCI 60 is non-blocking read 

return or ifthe message indicates some other change or changed condition within the referenced OLE object of the OLE 

hierarchy. A condition -change message may, for example, comprise an FMS locking message which prevents multiple 
users from accessing a particular block within a device of a process at the same time. If, for example, a block is being 
accessed by a different user by a hand-held communicator or another FMS system attached to the device, the OLE 
so object will identify such condition to the control through the DCI 60. Thereafter, the control may indicate to the user that 
the data of that block is no longer writable by, for example, displaying a gray background on the screen surrounding a 
normally writable value. 

[01 71J |n tne case of a non-blocking read return, a block 382 determines if the returned value has changed. If so, a 
block 384 stores this new value in the control cache. The block 384 and. if there has been no change in the data stored 
55 in the control cache, the block 382 as well, provides control to a block 386. The block 386 is also implemented if the 
block 380 determines that the message from the OLE object relates to a change not related to a non-blocking read. 
[0172] The block 386 determines if a change to the user interface is needed, such as if the changed data or the new 
condition or status is to be displayed on the screen. If so, a block 390 calls the change-user-interface routine 362 to dis- 
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play the changed data or the condition to the user. If, however, the block 386 determines that the changed data or the 
condition does not need to be displayed, or rf the block 390 has indicated such changed data or condition to the user, 
a block 392 determines if the application should be notified of the changed data or condition in accordance with pre- 
written instructions. II so, a block 394 sends a message to the current application 56 indicating the changed data or con- 

5 dition. Thereafter, control is returned to the block 315. 

[0173] Generally, information accessed by a device, a block, a parameter, or a timeline control can be displayed on a 
screen in any desired manner including (1) the EDIT style wherein the control behaves similarly to a normal Microsoft 
Windows Edit control. (2) the COMBO style wherein the control behaves similarly to a normal Microsoft Windows 
Combo Box control (i.e., as a drop down list). (3) the LIST style wherein the control behaves similarly to a normal Micro- 

w soft Windows List Box control (i.e., such that each hem in the enumeration will be represented as a list box entry). (4) 
the GROUP style wherein the control behaves similarly to a normal Microsoft Windows Group Box control, or (5) the 
PANEL style wherein the control displays either a raised or a sunken panel and/or any other desired style or format 
[0174] Fig. 20 illustrates control displays 400 and 402 associated with two device controls. Each of the device control 
displays 400 and 402 includes a picture or digital bitmap of the device (usually provided by a device manufacturer or 

is the DDS provider), which is stored in a memory associated with the current application. Instead, this bitmap may be 
stored in the database 40 so as to be accessible by the OLE objects. 

[0175] The control displays 400 and 402 may include any other desired information about a device including, for 
example, the name (illustrated in Fig. 20), tags, moniker, etc. of a device, or any other desired device-specific informa- 
tion. Furthermore, menus for the device can be provided in a pull-down window associated with the device control dis- 

20 plays 400 and 402. Such menus may include files associated with a device, for example, the names of the collections 
associated with a Device object for the device, methods which can be implemented on the device, including calibration, 
resetting, and self-testing methods, blocks associated with the device, a list of parameters associated with the device, 
help for the device, service notes for the device, etc. Other information about a device which may be displayed includes 
the contents of every variable of each parameter in a device, the face-plate information of a device, the operational sta- 

25 tus of the device, including, for example, whether an error has occurred within the device and a side-by-side list of. for 
example, the values of variables of one or more parameters of a device as they exist or existed at specified times. 
[0176] Fig. 21 illustrates a general parameter control display 406 along with particular parameter control displays 408. 
410. and 412 associated with three specific parameter controls for the parameters of a device. Each of the parameter 
" control displays 406-412 is located at a different portion on a screen and, in particular, the parameter control display 

30 406 is located at the top of the screen while the parameter control displays 408, 410 and 412 are located in sequence 
below the parameter control display 406. 

[0177] The parameter control display 406 illustrates that a parameter control display may have three fields, including 
a label field, which provides information pertaining to the type of information being shown, for example, "Pressure," 
"Temperature." or "Mode," a value field which shows the value of a parameter and a units field which indicates the units 

35 in which the value is expressed. The value of a parameter can be an integer number, & decimal number (parameter con- 
trol displays 408 and 410) or an enumerated value consisting of .oneof an enumerated set of values, as listed in a pull- 
down menu associated with the parameter control display 412. The parameter control display 412 does not include a 
units variable because such a variable is inapplicable to the enumerated set associated therewith. 
[0178] Fig. 22 illustrates two block control displays 414 and 416 associated with block controls. Similar to a device 

40 control display, a block control display typically includes a picture or other representation of a block and/or any other 
desired information pertaining to a block and/or the device in which the block is located including, for example, whether 
a block is an input, output, or control (or interface) block. 

[0179] Fig. 23 illustrates two timeline control displays 420 and 422 which are used to control and change the time and 
view properties of OLE Root objects to which other controls, such as device, block, and parameter controls may be con- 

45 nected. Each of the timeline controls associated with the displays 420 and 422 can change the time value of its respec- 
five. Boot object_to„any_ofjhe„previous.times.tor„which Root objects_are jayaHable, wJ^ch_wjlLtypiqalJyjnd the past 
times when changes were made to the system and for which transaction records 202 are stored in the transaction data- 
base 200 (Fig. 5) of the FMS database 40 (Fig. 1). Furthermore, the timeline controls associated with the control dis- 
plays 420 and 422 can change the view of a Root object between a past, a present, or a future setting. 

so [0180] Each timeline control display usually includes, as illustrated in Fig. 23, a slider 424 indicating which one of the 
past, present, and future views is selected as well as a combo box 426 which allows a user to select from a set of his- 
torical times, each having, for example, a date and a time. 

[0181] By changing the timeline control slider 424. the user tells the timeline control to change the Root object View 
property associated with that timeline control. By changing the timeline control combo box 426. the user tells the time- 
55 line control to change the Root object time value to a specified time. 

[0182] When a timeline control changes the time or view of a Root object, any other controls, such as parameter, 
device or block controls which are associated with that Root object will automatically be updated in response to change 
messages generated by the OLE objects. These change messages will be generated by the OLE objects when the OLE 
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objects within the same hierarchy as the Root object retrieve new data pertaining to the new time or view now associ- 
ated with the Root object. 

[0183] Rg. 23 also illustrates temperature- and pressure-parameter control displays 430 and 432 which are con- 
nected to the same Root object as the timeline control associated with the timeline control display 420. Likewise tem- 

5 perature and pressure parameter control displays 440 and 442 are connected to the same Root object as the timeline 
control associated with the timeline control display 422. Because the timeline control displays 420 and 422 are set to 
different times, i.e., a past time (control display 420) and the present (control display 422), the values of the temperature 
parameters 430 and 440 are different and the values of the pressure parameters 432 and 442 are different. A list of 
such parameter control displays can be configured on the screen to display one or more complete configurations for a 

io device, block etc. Device and block and/or other parameter controls can also be associated with the same Root object 
as timeline controls and can be used to illustrate a configuration display which shows a configuration of a device, a 
block, or a parameter at different times in a side-by-side or other relationship on a screen. A timeline control can also 
be used in conjunction with other controls on a display to scroll through the settings or values of devices, blocks or 
parameters or a set of such device, blocks, or parameters. As is evident, any desired combination of timeline, device, 

is block parameter and/or other controls may be used to illustrate any desired past and or present information to a user 
including, for example, information related to on-line devices at the present time, i.e., on-line data, and information 
related to on-line devices in the past or future, and to off-line devices in the past, present or future, i.e., off-line data. 
Furthermore, as indicated with respect to Fig. 23, the same data, for example, the same parameter values for a device, 
may be illustrated for different times using timeline controls and, if desired, routines may be implemented to indicate the 

20 differences between the sets of values. 

[0184] The timeline control changes the Time property of the Root object to a specific time (designated hereinafter 
as the ViewTime). which the user specifies using the timeline control. Consequently, the time attributes for all of the 
objects downstream of the Root object in the OLE hierarchy are changed to match the ViewTime as described above. 
In addition, the values of other properties of those objects are updated to the values corresponding to that ViewTime. 

25 [0185] For a Block object in particular, the state of the corresponding block at any desired time (e.g.. the ViewTime 
specified using the timeline control) is obtained using the above-described transaction database 200 (Fig. 5). More par- 
ticularly, the values of the parameters of the Block object at the ViewTime (i.e.. the values of the Value properties of the 
Parameter objects of the Block object as of the ViewTime) are obtained by searching the transaction database 200 in 
reverse-chronological order beginning at the ViewTime to find the values last assigned to the parameters corresponding 

30 to those Parameter objects on or before the ViewTime. This procedure is now described in detail with reference to the 
flowchart of Fig. 24. 

[0186] Fig. 24 is a flowchart illustrating how a state of a particular block can be reconstructed from the transaction 
database 200 described above. First, a block 450 initializes a "sef-type variable {S} to null. The set variable {S} is used 
to accumulate the values as of the ViewTime of the parameters of the block whose ViewTime state is to be recon- 
35 struct ed. A block 452 then sets a time associated with the set or state (S) equal to the ViewTime. Thereafter, a block 
454 determines whether the set variable {S} includes a value for each parameter of the Block Object. M it does, then a 
block 456 assigns the assembled state {S} as the state of the block at the ViewTime, and execution of the state recon- 
struction routine of Fig. 24 ends. 

[0187] If the block 454 determines that the accumulated state (i.e., the contents of the set variable {S}) does not 
40 include values tor every parameter in the block, then a block 458 identifies the next parameter P for which a current 
value is hot included in the accumulated state (S). A bloc k 460 then searches the transaction database 200 in reverse- 
chronological order beginning at the ViewTime to find the latest-made change TR made at or before the ViewTime. A 
block 462 then adds the parameter P. with the value of the parameter P set by the change represented by transaction 
TR, to the accumulated state [S). and control then returns to the block 454 to check once again, whether values of all 
45 parameters in the block have now been accumulated in the state {S}. 

[0188] Although the device, block parameter, and timeline controls are illustrated and described herein, other controls 
according to the present invention could be constructed to illustrate other properties or data available through DDL, 
including data within any of the OLE objects illustrated in Figs. 3 and 4. 

[0189] While the present invention has been described with reference to specific examples, which are intended to be 
so illustrative only, and not to be limiting of the invention, it will be apparent to those of ordinary skill in the art that changes, 
additions and/or deletions may be made to the disclosed embodiments without departing from the spirit and scope of 
the invention. 

S5 
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OLE object^dl""eqdtvalents 



The following table explains the correspondence between 
the OLE hierarchy described above and the related constructs in 
the DDL. As used in the table, the term "Host device" means an 
FMS system or an FMS application. Further, the actual keywords 
employed by a particular DDL may vary, and the proper keywords 
for a particular DDL will be provided in the specification 
provided for that DDL. The following table is based on the 
Fieldbus Device Description Language, which is similar to the 
HART Device Description Language. 



OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


AxrayParameter object 


The DDL equivalent is an array, 
which is a logical group of 
values. Each value, or element, 
is of the data type of a DDL 
variable. An element may be 
referenced from elsewhere in the 
device description via the array 
name and the element index. DDL 
arrays describe communication 
array objects. Therefore, from 
a communication perspective, the 
individual elements of the array 
are not treated as individual 
variables, but simply as 
individual values . * 


Block object 


The DDL equivalent is a block, 
which defines the external 
characteristics of a DDL block. 


Collection object 

This OLE object represents a 
particular object in the 
Collections collection 
object. 

(see Collections) 


The DDL equivalent Is a 
collection, which is a logical 
group of members. Each member 
in the group is assigned a name. 
The members may be referenced in 
the device description by using 
a collection name and a member 
name . 
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OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


Collectionlteme collection 
object ("Member") 


The DDL equivalent is a 
collection, which is a logical 
group of members . Each member 
in the group is assigned a name. 
The members may be referenced in 
the device description by using 
a collection name and a member 
name. 


Collections collection object 
("Collection") 


The closest DDL equivalent is a 
collection, which-is a logical 
group of items (in this case 
collections) . Each collection 
in the group is assigned a name. 
The collections may be 
referenced from in the device 
description by using the 
collection name and the name of 
the collection of collections. 


DatabaseParameters collection 


There is no DDL equivalent to 
this OLE collection object, 
which exists only in the FMS 
database. This object relates 
to a collection of parameters 
stored in a database. 


a> a "V"» a e a B a v a tti a fr" ^ T" O r"i "1 O ^ 
XJci t ox) cL B V Mr AX OJUti C <L \JKJ J w W W 
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There is no DDL equivalent to 
this OLE object, which exists 
only in the FMS database. This 
object relates to a parameter 
stored in a database. 


EditDisplay object 


The DDL equivalent is an edit 
display, which defines how data 
will be presented to a user by a 
host. It is used to group items 
together during editing. 


EditDi splay I terns collection 
object ("Display" and "Edit") 


The DDL equivalent is a 
collection of edit items, which 
are a set of block parameters 
and elements of block parameters 
to be edited by the user. The 
display items are provided to 
allow the user to decide what 
the values of the edit items 
should be. 


EditDi splays collection 
object ("EditDisplay") 


The DDL equivalent is a 
collection of edit displays, 

which define how data will be 
presented to a user by a host. 
They are used to group items 
together during editing. 
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OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


5 
TO 


Elements collection object 
( "Element" ) 


The DDL equivalent is a 
collection or group of elements, 
which specify one item (such as 
a variable or menu) in the 
group, and is defined by a group 
of four parameters (index, item, 
description and help) . 


75 
20 


EnumerationValue ob j ect 


The DDL equivalent is a variable 
of the enumeration type . Such 
variables include enumerated 
variables, which are unsigned 
integers that have a text string 
associated with some or all 
values (useful, for defining 
uacxes, cor example; , and bit* 
enumerated variables, which are 
unsigned integers that have a 
text string associated with some 
or all bits (useful in defining 
status octets) . 


25 


EnumerationValues collection 
Object ("Enum") 


The DDL equivalent is a 
collection of variables of the 
enumeration type . 




ItemArray collection object 
( n Indexedl temArray " ) 


The DDL equivalent is a 
collection of item arrays. 


30 
35 
40 


ItemArray object 


The DDL equivalent is an item 
array, which is a logical group 
of items, such as variables or 
menus. Each item in the group 
is assigned a number, called an 
index. The items can be 
referenced from ' elsewhere in the 
device description via the item 
array name and the item number. 
Item arrays are merely groups of 
DDL items and are unrelated to 
communication arrays (item type 
"ARRAY" ) . Communication arrays 
are arrays of values. 


45 
50 


ItemArrayltems collection 
ob j ect ( ■ El ement ■ ) 


The DDL equivalent is an 
element, an attribute of an item 
array which identifies elements 
of the item array. Each item 
array element specifies one item 
(such as a variable or menu) in 
the group, and is defined by a 
group of four parameters (index, 
item, description and help) . 
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OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


ItenArraye collection object 
("ItemArray" ) 


The DDL equivalent is a 
collection of item arrays* 


Members collection object 
("Member") 


The DDL equivalent is a 
collection of members, which are 
variables, records, and/or 
arrays. 


Menu object 


The DDL equivalent is a menu, 
which organizes parameters, 
methods, and other items 
specified in the DDL into a 
hierarchical structure. A host 
application may use the menu 
items to display information to 
the user in an organized and 
consistent fashion. 


MermI terns collection object 
("Menultem") 


The DDL equivalent is a 
collection of menus items. The 
items of a menu specify the 
items associated with the menu 
plus an optional qualifier. 


Menus collection object 
( "Menu" ) 


The DDL equivalent is a 
collection of menus. 


Method object 

ii 


The DDL equivalent is a method, 
which describes the execution of 
complex interactions that must 
occur between host devices and a 
field device . 


Methods collection object 
("PreEdit", "Post Edit", and 
"Method") 


The DDL equivalent is a 
collection of methods. 


NamedConfig object 


There is no DDL equivalent to a 
NamedConfig object because these 
objects correspond to blocks 
that are stored in the FMS 
database rather than in field 
devices . 


Parameters collection object 
("Param") 


The DDL equivalent is a 
collection of parameters, which 
may be records, arrays, or 
variables . 
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OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


RecordParameter object 


The DDL equivalent is a record, 
which is a logical group of 
variables. Each variable in the 
record is assigned a DDL 
variable name. Each variable 
may have a different data type. 
The varicibles may be referenced 
from elsewhere in the device 
description via the record name 
and the member name: DDL 
records describe communication 
record objects. Therefore, from 
a communication perspective, the 
individual members of the record 
are not treated as individual 
variables, but simply as a group 
of variable values . 


Ref reshKelation object 


The DDL equivalent is a refresh 
relation, a particular type of 
relation which allows the host 
device to make decisions 
regarding parameter value 
consistency when a parameter 
value changes. It specifies a 
set of block parameters which 
may need to be refreshed (re- 
read from the device) whenever a 
block parameter from another set 
is modified. A block parameter 
can have a refresh relationship 
with itself, implying that the 
block parameter must be read 
after writing. 

Occasionally writing a block 
parameter to a field device 
causes the field device to 
update the values of other block 
parameters. If the additional 
updated block parameters are 
dynamic, there is no conflict 
because the host device should 
re-read the parameter values 
from a failed device each time 
the values are needed. However, 
host devices may cache the 
values of static block 
parameters. Therefore, for host 
devices to maintain the correct 
values of all static block 
parameters, they need to know 
when the field device is 
changing its values. 
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OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


Ref reehRelationa collection 
object ("Refresh") 


The DDL equivalent is a 
collection of refresh relations. 


Relationltems collection 
object ("Units" , "Members", 
"Left", and -Right-) 


The DDL equivalent is a 
collection of parameters, which 
may be variables, records, 
and/or arrays. 


ReeponeeCode object 


The DDL equivalent is a response 
codes, which specifies the 
values a field device may return 
as application-specific errors. 
Each variable, record, array, 
variable list, program, or 
domain can have its own set of 
response codes, because each one 
is eligible for FMS services. 


ResponseCodes collection 
object ( "RespCode" ) 


The DDL equivalent is a 
collection of response codes. 


UnitRelation object 


The DDL equivalent is a unit 
relation, which specifies a 
units code parameter and the 
block parameters with those 
units. When a units code 
parameter is modified, the block 
parameters having that units 
code should be refreshed. In 
this respect, a unit relation is 
exactly like a refresh relation. 
In addition, when a block 

displayed, the value of its 
units code will also be 
displayed. 


UnitRelatione collection 
object ("Unit") 


The DDL equivalent is a 
collection of unit relations. 


VariableParamcter object 


The DDL equivalent is a 
variable, which describes data 
contained in a device. 
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OLE OBJECT (Lower Hierarchy) 


DDL EQUIVALENT 


WriteAsOne Relation object 


The DDL equivalent is a write- 
as -one relation, which informs 
the host device that a group of 
block parameters needs to be 
modified as a group. This 
relation does not necessarily 
mean the block parameters are 
written to the field device at 
the same time. Not all block 
parameters sent to the field 
device at the same time are 
necessarily part of a write-as- 

/•\th» y-ol " *T ^ 2k ^ t T ^ c±\r i ^ a 

requires specific block 
parameters to.be examined and 
modified at the same time* for . 
proper operation, a write-as-one 
relation is required. 


WriteAoOneRelations 
collection object ("WAO 11 ) 


The DDL equivalent is a 
collection of write-aa-one 
relations. 
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OLE OBJBtT DEFINITIONS 



The following tables illustrate the properties and methods 
of the various OLE objects and collection objects in the lower 
hierarchy illustrated in Fig. 4. The various properties of 
those objects and collection objects are not included in the 
following table, but those properties correspond to the 
attributes of the DDL objects which are equivalents of the 
objects. The DDL equivalents of the OLE objects and collection 
objects are identified in the OLE object DDL equivalents table, 
and are fully described in the ISP Fieldbus DDL specification 
document, incorporated by reference herein. 

The following tables use the following symbols to denote 
the following information: 

(R) Access the property via the Read/Write and Get /Set 
methods . 

( r ) Read/Write . 

(tt) Read/Write in devices less than Rev. 5; otherwise, 
read-only. 

(M) Run this method by executing the OLE method called 
"Method- or "Cal lMethod" 

(N) Not implemented. 

(C) Access this property via an OLE property. Get 
method, or a Read request containing only this 
property . 

The values referenced in the Return Type column indicate 
the following VARIANT types: 



VT 


EMPTY 


Used whpn no-value is available. 


VT" 


J 4 


Used for integer values and boolean 






values . 


VT_ 


_R4 


Used for most floating point field 






measurement values. 


VT_ 


_R8 


Used for double precision measurement 






values - 


VT_ 


DATE 


Used for dates and times using double 






precision. 


VT 


BSTR 


Used for character strings. 


VT~ 


"ERROR 


Used for error codes - 


VT* 


"array 


Used for binary values. 



All objects defined in this table have the set of Standard 
Properties listed below. 
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Standard Properties 


Property Name 


Return Type 


Description 


Kind (R) 


VTJ4 


Returns the object's kind. 


KindAsString (R) 


VT_BSTR 


Returns the object's kind as a string. 


Moniker (P) 


VT_BSTR 


Returns a full moniker tor the object 



15 





ArrayParameter Object 




Property Name 


Return Type 


Description 


20 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all 
the items in the collection can be accessed without blocking. 




ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without 
blocking, which may be less than the total number of items in the col- 
lection. 


ServerCount (N) 


VT_I4 


Same as the Count property except it does not block if all the Herns 
are not immediately available. 




Name (R) 


VT_BSTR 


The parameter'6 (or record member's) name. 


30 


Memberld (R) 


VT_I4 


The parameter's (or record member's) member ID. 




Itemld (R) 


VTJ4 


The array's item ID. 




Paramlndex (R) 


VT_I4 


The parameter's (or array element's) index. 


35 


ParamLabel (R) 


VT_ BSTR 


The parameter-specific label. 


Label (R) 


VTJ3STR 


The array-specific label. , 




ParamHelp (R) 


VT.BSTR 


The parameter-specific help. 




Help (R) 


VT_BSTR 


The array-specific help. 


40 


NumberOfElements (R) 


VT_I4 


The number of elements in the array. 




Method Name 


Return Type 


Description 




Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collec- 
tions provided by the object. 


45 






Collections: 

The "Element" collection is an Elements collection and contains the 
array's elements. 


SO 






The "RespCode" collection is a ResponseCodes collection and con- 
tains the array's response codes. 




_NewEnum 


VT^UNKNOWN 


Returns the lUnknown interface of an object that implements the 
lEnumVariant interlace. 



55 
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Block Object 



Property Name 


Return 
Tvpe 

J Mr 


Description 


Count (C) 


VT_I4 


The number of items in the 
collection. This property 
blocks until all the items in 
the collection can be accessed 
without blocking. 


ReadyCount (C) 


VT_I4 


The number of items in the 

COllCCUlOn Liiob Coil JEJc aLtcsScU 

without blocking, which may be 
less than the total number of 
items in the collection. 


ServerCount (N) 


VT_14 


Same as the Count property 
except it does not block if all 
the items are not immediately 
available . 


Name (R) 


VT BSTR • 


The block's name. 


Itemld (R) 


VT 14 


The block's item id. 


Label (R) 


VT BSTR 


The block's label. 


Help (R) 


VT BSTR 


The block's help. 


Tag (R) 


VT__BSTR 


The block's internal tag. 
Note: 

For a HART block, this is the 
HART tag. 




BlockTag (R) 


VT BSTR 


The block's external tag. 


PhysicalTag (R) 


VT_BSTR 


The internal tag of the device 
in which the block resides. 

Note: 

For a HART device, this is the 
HART tag. 


DeviceTag (R) 


VT_BSTR 


The external tag of the device 
in which the block resides . 


DevicelD (R) 


VT_BSTR 


The unique identifier of the 
device in which the block 
resides . 


NetAddress (R) 


VT_BSTR 


The network address, as a 
moniker, of the device in which 
the block resides. 


StationAddress (R) 


VT_I4 


The station address of the 
device in which the block 
resides. 
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Method Name 


Return Typ* 


Description 


5 
10 


Item 


VT_DIS PATCH 


Takes one argument of type 
VT_BSTR and returns one of the 
collections provided by the 
object. 
Collections : 


15 






The "Param" collection is a 
Parameters collection and 
contains the block's 
parameters . 






The "Database" collection is a 
DatabaseParameters collection 
and contains, the database 
parameters for the block. 


20 
25 






The "Method" collection is a 
Methods collection and 
contains the block's methods. 
The "Menu" collection is a 
Menus collection and contains 
the block's menus. 


30 






The "EditDisplay" collection 
is an EditDisplays collection 
and contains the block's edit 
id i splays. 


35 






The "ItemAxray" collection is 
an ItemArrays collection and 
contains the block's item 
arrays . 

The „" Collection" collection is 
a Collections collection and 
contains the block's 
collections. 


40 






The "Refresh" collection is a 
Ref reshRelations collection 
and contains the block's 
refresh relations. 


45 






The "Unit" collection is a 
UnitRelations collection and 
contains the block's unit: 
relations . 


50 






The "WAO" collection is a 
WriteAsOneRelations collection 
and contains the block's write 
as one relations. 



55 
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Method Name 


Return Type 


Description 


_NewEnum 


VT_UNKNOWN 


Returns the IUnknown interface 
of an object that implements 
the IEnumVariant interface. 


Invalidate (M) 


VT_EMPTY 


Invalidates the parameters in 
the parameter cache. This 
method is used to force all 
the parameters to be re-read 
from the device. 


SendCommand (M) 


VT_ EMPTY 


Sends a HART command. Takes 
two arguments of type VT_ 14 
which specify the command 
number and the transaction 
number. 


SendContinuous 
Command (M) 


VT_EM?TY 

it 


Sends two HART commands 
continuously. Takes six 
arguments of type VT_I4 . The 
first three arguments specify 
the first command to be sent 
and the last three arguments 
specify the second command to 
sent. The first and fourth 
arguments specify command 
numbers, the second and fifth 
arguments specify transaction 
numbers, and the third and 
sixth arguments specify the 
number of times to send the 
specified commands. 


FindResponseCode 
(M) 


VT_BSTR 


Returns the string associated 
with a response code of a HART 
command. Takes three arguments 
of type VT_I4 which specify 
the command number, the 
transaction number and the 
response code value- 
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BlockTag Collection 


Property Name 


Return Type 


Description 


Count (N) 


VT — 14 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


Readyoount (imj 


\rr \a 


i ne numoer or items in ine collection mai can ue accesseo wiuioui DiocKing, 
which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. The Block object whose BlockTag property matches the argu- 
ment is returned. 


_NewEnunfi (N) 


VTJJN KNOWN 


Returns the (Unknown interface of an object that implements the lEnum Var- 
iant interface. 



25 





Collections Collection 




Property Name 


Return Type 


Description 


30 


Count(C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 




ReadyCount (C) 


VT_I4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 


35 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 




Method Name 


Return Type 


Description 


40 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

If the argument begins with a $, the rest of the string must take the form of 
an integer. The DDL collection whose itemld property matches the argu- 
ment is returned. 


45 






If the argument begins with a digit, the string must take the form of an integer 
and the DDL collection whose Index property matches the argument is 
returned. 


50 






Otherwise; the DDL collection whose Name property matches the argument 
is returned. 


JMewEnum 


VT_UNKNOWN 


Returns the 1 Unknown interface of an object that implements the lEnumVar- 
iant interface. 
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Collectionltems Collection 


5 


Property Name 


Return Type 


Description 




Count (C) 


VT_I4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCourrt (N) 


VTJ4 


Same as the Count property except it does not block rf all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


20 






If the argument begins with a $, the rest of the string must take the form of 
an integer. 






The item whose ItemMemberlD property matches the argument is 
returned. ■ , 


25 






Otherwise, the item whose ItemName property matches the argument is 
returned. 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 



30 



Collectionltem Object 


Property Name 


Return Type 


Description 


ItemName (R) 


VT_BSTR 


The collection item's member name. 


ItemMemberld (R) 


VTJ4 


The collection item's member ID. 


ItemLabel (R) 


VTJ4 


The collection item's label. 


ItemHelp (R) 


VT_BSTR 


The collection item's help. 



45 



55 
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Collection Object 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadvCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block rf all the items are not 
immediately available. ■ 1 


Name (R) 


VT_BSTR 


The collection's name. 


ttemld (R) 


VTJ4 


The collection's Hem ID. 


Index (R) 


VTJ4 


The collection's index. 


Label (R) , 


VT_BSTR 


The collection's label. 




VT BSTR 


The cnilectiorTfi KiaId 


Type(R) 


VTJ4 


The collection's type. 


TypeAsString (R) 


VT_BSTR 


The collection's type as a string. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object 

Collections: ' 

The "Member" collection is a Collection Items collection and contains the 
members of the DDL collection. 


_NewEnum 


\TTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface 



Data basePa ra meter Object 


Property Name 


Return Type- 


Description 


Name (R) 


VT_BSTR 


The parameter's name. 


Value (R) (t) 


VT^VARIANT 


The parameter's value. 


ValueAsString (R) (t) 


VT_BSTR 


The parameter's value as a string. 


Size (R) 


VT_I4 


The parameter's size (in bytes). 


Type (R) 


VT_I4 


The parameter's type. 


TypeAsString 


(R) vT_BSTR 


The parameter's type as a string. 



55 
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DatabaseParameters Collection 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be stressed without blocking, 
which may be less than the total number of items in the collection. 


ServerCount (N) 


VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT_D1SPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The DatabaseParameter object whose Name property matches the argu- 
ment is returned. 


_NewEnum 


VT_UNKNOWN 


Returns the (Unknown interface of an object that implements the lEnum Var- 
iant interface. 



25 



DevicelD Collection 


M 


Property Name 


Return Type 


Description 


Count (N) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (N) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The Device object whose DevicelD property matches the argument is 
returned. 


_NewEnum (N) 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnum Var- 
iant interface. 



55 
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Device Object 


Property Name 


Return Type 


Description 


Count (C) 


VT 14 


The number of items in the collection. This property blocks until all the 
items in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without 
blocking, which may be less than the total number of items in the col- 
lection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are 
not immediately available. 


PhvsicalTaa (R)(t) 


VT_BSTR 


The device's internal tag. 
Note: 

For a HART device, this is the HART tag. 


DeviceTag (R) 


VT_BSTR 


The device's external tag. 


DevicelD (R)(t t) 


VT_BSTR 


The device's unique identifier. 


StationAddress 
(R)(t) 


VT_»4 


The device's station address. 


NetAddress (R) 


VT_BSTR 


The device's network address as a moniker. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the codec- . 
tions provided by the object 

Collections: 

The "Tag" collection is a Tag collection and contains all the device's 
blocks. 

Special Case: 

If the argument is "HART," the IDispatch interface of the device's Block 
object is returned. 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the 
lEnumVariant interface. 
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DeviceTag Collection 


Property Name 


Return Type 


Description 


Count (N) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (N) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT.DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The Device object whose DeviceTag property matches the argument is 
returned. 


_NewEnum (N) 


VTJJNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iant interface. 




EditDisplayltems Collections 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block tf all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT.DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the item whose Index 
property matches the argument is returned. 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 
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EditDisplays Collection 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the hems in the 
collection. 


20 






11 the argument begins with a $, the rest of the string must take the form of 
an integer. The edit display whose Item Id property matches the argument is 
returned. 

If the argument begins with a digit, the string must take the form of an inte- 
ger and the edit display whose Index property matches the argument is 
returned. 


25 






Otherwise, the edit display whose Name property matches the argument is 
returned. 




_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 



30 



35 



40 



45 
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Ed'rtDisplay Object 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of ilems in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


TO 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than all the items in the collection. 




Ocl VclUOUlU V 1 '/ 




oomc So uic wtiiini properly except n uuco iiui Lntjun n cm uic ixemo are noi 

immediately available. 


75 


Name (R) 


VT_BSTR 


The edit displays name. 




VT Id 


i 'ic wjn uiofJ*ciy o iiv 1 1 iu. 




Index (R) 


VTJ4 


The edit displays index. 




Label (R) 


VT_BSTR 


The edit displays label. 


20 


Method Name 


Return Type 


Description 




item 


VT_DISPATCH 


Takes an argument of type 

VT_BSTR and returns one collection of the object 


25 






Collections: 






The "Edit* collection is an EditDisplayltems collection and contains the edit 
display's edit items. 


30 






The "Display" collection is an EditDisplayltems collection and contains the 
edit display's display Hems. 






The "PreEdrt" collection is a Methods collection and contains the edit dis- 
play's pre-edit methods. 


35 






The "PostEdit" collection is a Methods collection and contains the edit dis- 
play's post-edit methods. 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnum Var- 
iant intorfaoe. ~ 




ExecutePreEdrt 


VT_EMPTY 


Executes the edit display's pre-edit methods. 


40 


ExecutePostEdit 


VT_EMPTY 


Executes the edit display's post-edit methods. 



45 
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Elements Collection 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




oerveruount (N) 


\/TT \A 

VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


ivieinuu name 


rteiurn type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


20 






If the argument begins with a $, the rest of the string must take the form of an 
integer. The element whose (tern Id property matches the argument is 
returned. 

Otherwise, the string must take the form of an integer. The element whose 
Paramlndex property equals this integer is returned. 


25 


_NewEnum 


VT_UNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iant interface. 



t »1 
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40 



45 



SO 
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EnumerationValue Object 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until 
all the items in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VT_I4 


The number of items in the collection that can be accessed with- 
out blocking, which may be less than the total number of items in 

the rv\Hor*finn 




oer ver oouni yrs) 


V 1 l*T 


fiflmo ac thp finnnt nronArtv excent rt does not block if all the 

items are not immediately available. 


15 


Description (R) 


VT.BSTR 


The enumeration value's description. 




Value (R) 


VT_I4 


The enumeratibn value. 




Help (R) 


VT_BSTn 


The enumeration value's help. 


SO 


Class (R) 


VTJ4 


The enumeration value's class. 




CtassAsString (R) 


VT_BSTR 


The enumeration value's class as a string. 




StatusClasses (R) 


VTJ4 


The enumeration value's status classes. 




StatusClassesAs String (R) 


VT_BSTR 


The enumeration value's status classes as a string. 


25 


Method Name 


Return Type 


Description 




Item 


VT_DISPATCH 


Takes one argument of type VTJBSTR and returns one of the col- 
lections provided by the object. 


30 






.Collections; 






The "Member*' collection is a Collectionltems collection and con- 
tains the members of the DDL collection. 


35 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the 
lEnumVariant interface. 


ExecuteActions 


VTEMPTY 


Executes the enumeration value's actions method. 



40 



45 



SO 
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EnumerationVatues Collection 


5 




Return TvrfcO 


Descriotion 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCount (R) 


VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the Hems in the 
collection. 


20 


• 




If the argument begins with a digit, the string must take the form of an integer 
and the enumeration value whose Value property matches the argument is 
returned. 

Otherwise, the enumeration value whose Description property matches the 
argument is returned. 


25 


_NewEnum 


NTTJJNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iant interface. 


30 










HIU Collection 




Property Name 


Return Type 


Description 


35 


Count (C) 


VT_t4 


The number of items in the collection. This.property blocks until all the items 
in the collection canbe accessed without blocking. 




ReadyCount (C) 


VT_I4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


40 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 




Method Name 


Return Type 


Description 


45 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the Interchange object 
whose StationAddress property matches the argument is returned. 


SO 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVcir- 
iant interface. 
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Interchange Object 


5 


Property Name 


Return Type 


Description 




Count (C) 


VT_W 


The number of items in the collection. This property blocks until all the 
items in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VT_W 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCount (N) 


VT_»4 


Same as the Count property except it does not block if all the items are 
not immediately available. 




Tag (R)(t) 


VT_BSTR 


The HART Interchange's HART tag. 


IS 


Device ID (R) 


VT_BSTR 


The HART Interchange's unique identifier. 




NetAddress(R) 


VT_BSTR 


The HART Interchange's network address as a moniker. 




Station Address fR) 


VT_*4 


The HART Interchange's station address. 


so 


Method Name 


Return Type 


Description 




Item 


VTJDISPATCH 


Returns the IDispatch interface of the specified device on the Instrument 
List. This method takes one argument which is a loop number, 0-31 inclu- 
sive. 


25 






Or 

"Block," which returns the IDISPATCH interface to the Block Object that 
describes the HIU itself. . 


30 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnum- 
Variant interface. 



35 



40 



45 



50 
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ItemArray Object 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block rf all the items are not 
immediately available. 


Name(R) 


VT_BSTR 


The item array's name. 


ItemkJ (R) 


VTJ4 


The item array's item ID. » 


Index (R) 


VTJ4 


The item array's index. 


Label (R) 


VT_BSTR 


The item array's label. 


Help (R) 


VT_BSTR 


The item array's help. 


Type(R) 


VTJ4 


The item array's type. 


TypeAsString (R) 


VT.BSTR 


The item array's type as a string. 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object. 

Collections: 

The "ElernenT collection is an ItemArrayltems collection and contains the 
elements of the item array. 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 



35 



40 



45 



SO 



BMcnnrirv ^cd naai <o * *«-» t - 



50 



EP0 961 184 A2 





HemArrays Collection 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 




Method Name 


Return Type 


Description 


15 


Hem 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


20 






If the argument begins with a $, the rest of the string must take the form of 
an integer. The Hem array whose Item Id property matches the argument is 
returned. 

K the argument begins with a digit, the string must take the form of an inte- 
ger and the Hem array whose Index property matches the argument is 
returned. 


25 






Otherwise, the item array whose Name property matches the argument is 
returned. 




_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 



30 



ItemArrayltem Object , 


Property Name 


Return Type 


Description 


Hemlndex (R) 


VT_BSTR 


Tne item array item's index. 


KemLabel (R) 


VT_I4 


The Hem array item's label. 


ItemHelp (R) 


VT_BSTR 


The Hem array item's help. 



45 



50 
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ItemArrayttems Collection 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VT_W 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


Server Count (N) 


VT_W 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 

i 


VT^DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the item whose Kemtn- 
dex property matches the argument is returned. 


_NewEnum 


VTJJNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iant interface. ' 



30 


Members Collection 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


35 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCourrt (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


40 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. *™ 


45 






If the argument begins with a $, the rest of the string must take the form of a 
DDID (an integer). If the DDID is an item ID, the member whose Itemtd prop- 
erty matches the argument is returned. If the DDID is a member ID, the 
member whose Member Id property matches the argument is returned. 


SO 






H the argument begins with a digit, the string must take the form of an integer 
and the parameter whose Paramlndex property matches the argument is 
returned. 






Otherwise, the parameter whose Name property matches the argument is 
returned. 


55 


_NewEnum 


VT_UNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iarrt interface. 
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Menultems Collection 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that pan be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the item whose Index 
property matches the argument is returned. 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 



25 



Menultem Object , 


Property Name 


Return Type 


Description 


Flags (R) 


VTJ4 


The menu item's flags. 


FlagsAsString (R) 


VT_BSTR 


The menu Hem's flags as a string. 



40 



45 



50 
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Menu Object 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VT_W 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Name (R) 


VT_BSTR 


The menu's name. 


Itemld(R) 


VT_W 


The menu's item id. 


Index (R) 


VT_W 


The menu's index. 


Label (R) 


VT_BSTR 


The menu's label. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object. 

Collections: 

The "Menu Item" collection is a Menu Hems collection and contains the items 
of the menu. 


_NewEnum 


VT_UNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iant interface. 
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Menus Collection 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


20 






If the argument begins with a $, the rest of the string must take the form of 
an integer. The menu whose Item Id property matches the argument is 
returned. 

it xne argument Degins wim a aigu xne siring musx lane tne Torm oi an integer 
and the menu whose Index property matches the argument is returned. 


25 






Otherwise, the menu whose Name property matches the argument is 
returned. 




_NewEnum 


VTJJNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iarrt interface. 


30 








35 


Methods Collection 


Property Name 


Return Type 


Description ' 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


40 


ReadyCount (C) 


VT_14 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


45 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


50 






If the argument begins with a $, the rest of the string must take the form of 
an integer. The method whose Itemld property matches the argument is 
returned. 

If the argument begins with a digit, the string must take the form of an integer 
and the method whose Index property matches the argument is returned. 


55 






Otherwise, the method whose Name property matches the argument is 
returned. 




_JMewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iarrt interface. 
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Method Object 


Property Name 


Return Type 


Description 


Name (R) 


VTJ3STR 


The method's name. 


ItemID (R) 


VT_I4 


The method's item ID. 


Index (R) 


VTJ4 


The method's index. 


Class (R) 


VTJ4 


The method's class. 


ClassAsString (R) 


VT_BSTR 


The method's class as a string. 


Definition (R) 


VT_BSTR 


The method's definition. 


Label (R) 


VT_BSTR 


The method's label. 


Help (R) 


VT_BSTR 


The method's help. 


Validity (R) 


VTJ4 


The method's validity. 


Method Name 


Return Type 


Description 


Execute 


VT_EMPTY 


Executes the method. 



Modem Collection 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the Device object whose 
StationAddress property matches the argument is returned. 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVSar- 
iant interface. 



so 
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40 



NamedConfigs Collection 


Property Name 


Return Type 


Description 


Count (N) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCourrt (N) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The NamedConfig object whose Name property matches the argument is 
returned. 


JMewEnum (N) 

i 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnum Var- 
iant interface. 




Net Collection • 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCourrt (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The NetNode object whose Name property matches the argument is 
returned. 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnum Var- 
iant interlace. 



so 
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NetNode Object 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCourrt (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCourrt (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Name (R) 


VT_BSTR 


The node's TCP/IP node name. 


Address (R) 


VT_BSTR 


The node's TCP/IP address in dot address format. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object 

Collections: 

* port name (returns a Port collection, e.g.. COM1 or COM2) 
Note: ' 

In the future, access to the RS3. PROVOX. and HAWK control systems will 
also be provided. 


_NewEnum 


VTJJNKNOWN 


Returns the I Unknown interface of an object that implements the lEnumVar- 
iant interface. 
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Parameters Collection 


5 


property rvame 


Datum Tuno 

nciurn type 


noQrrint inn 

Uwblipilvll 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 




Method Name 


Return Type 


Description 


15 


Item 


VTJDISPATCH 


Takes one argument of type VTJ5STR and returns one of the items in the 
collection. 


20 






If the argument begins with a $, the rest Of the string must take the form of 
a DDID (an integer). If the DDID is an item id, the parameter whose Itemld 
property matches the argument is returned. If the DDID is a MemberkJ, the 
parameter whose Memberld property matches the argument is returned. 


25 






If the argument begins with a digit, the string must take the form of an irtte- 
ger and the parameter wnose ra rami no ex property maicnes uie argument 
is returned. 






Otherwise, the parameter whose Name property matches the argument is 
returned. 


30 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iarrt interface. .» 


35 










PhysicalTag Collection 




Property Name 


Return Type 


Description 


40 


Count (N) 


VT_I4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 




ReadyCount (N) 


VT_W 


The number of items in the collection that can be accessed without block- 
ing/which may be less than the total number of items in the collection. 


45 


ServerCount (N) 


VT_14 


Same as the Count property except it does not block if all the items are not 
immediately available. 




Method Name 


Return Type 


Description 




Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


SO 






The Device object whose PhysicalTag property matches the argument is 
returned. 




_NewEnum (N) 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 
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Port Collection 


5 


Property Name 


Return Type 


Description 




Count(C) 


VT_W 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCount(N) 


VT_!4 


Same as the Count property except it does not block rf all the items are not 
immediately available. 


IS 


Method Name 


Return Type 


Description 




Item 


VT_D1SPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object 

Collections: 


SO 






The "HILT collection is a HIU collection and contains all the HART Inter- 
changes accessible via the port. 

The "Modem" collection is a Modem collection and contains all the HART 
devices accessible via the port. 


25 


_NewEnum 


\TT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interlace. 



35 



40 



45 



SO 
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RecordParameter Object 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


70 


ReadyCount (C) 


VT_I4 


The number of items in the collection that can be accessed without block- 
ing, wnicn may De less tnan tne total numDer or iierns in ine collection. 




ServerCount (N) 


VT_I4 


bame as trie oount property except it Goes not diock it an me rtems are not 
immediately available. 




Name (R) 


VT.BSTR 


The parameter's (or record member's) name. 


75 


Member Id (R) 


VT_I4 


The parameter's (or record member's) member id. 




Itemld (R) 


VT_I4 


The record's item id. 




Paramlndex (R) 


VT_14 


The parameter's (or array element's) index. 


20 


ParamLabel (R) 


VT_BSTR 


The parameter-specific label. 




Label (R) 


VT_BSTR 


The record-specific label. 




ParamHelp (R) 


VT_BSTR 


The parameter-specific help. 


25 


Help (R) 


VT_BSTR 


The record-specific help. 


M«>thrtr! NamA 

IVItrlllUU I^OlliC 


Return Tvda 


De&criotion 




Item 


VT.DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object. 


30 






Collections: 






The "Member" collection is a Members collection and contains the record's 
members. 


35 






The "RespCode" collection is a ResponseCodes collection and contains 
the record's response codes. 




_NewEnum 


NTTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 



40 



45 



50 
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RelreshRelation Object 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCourrt (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Name (R) 


VT_BSTR 


The refresh relation's name. 


Itemld (R) 


VTJ4 


The refresh relation's item ID. 




Index (R) 


VT_I4 


The refresh relation's index. 




Method Name 


Return Type 


Description 


SO 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object 

Collections: 


25 






The "Left" collection is a Relationltems collection and contains the parame- 
ters on the left side of the refresh relation. 

The "Right" collection is a Relationltems collection and contains the param- 
eters on the right side of the refresh relation. 


30 


_NewEnum 


VTJJNKNOWN 


Returns the 1 Unknown interface of an object that implements the lEnumVar- 
iant interface. 



35 



40 



45 



SO 
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RefreshRelations Collection 


5 


Prooertv Naim 


Return Type 


Descrlotlon 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the hems in the 
collection. 


20 






If the argument begins with a $, the rest of the string must take the form of an 
integer. The refresh relation whose Item Id property matches the argument is 
returned. 

If the argument begins with a digit, the string must take the form of an integer 
and the refresh relation whose Index property matches the argument is 
returned. 


25 






Otherwise, the refresh relation whose Name property matches the argument 
is returned. 




_NewEnum 


VT_UNKNOWN 


Returns the 1 Unknown interface of an object thatimplements the lEnum Vari- 
ant interface. 



30 



ResponseCode Object , 


Property Name 


Return Type 


Description 


Value (R) 


VT_I4 


The response code's value. 


Type(R) 


VT_I4 


The response code's type. 


Description (R) 


VT_BSTR 


The response code's description. 


Help (R) 


VT_BSTR 


The response code's help. 



45 



SO 
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Relationltems Collection 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCourrt (C) 


VT_I4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount(N) 


VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VTJDISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the item whose Index 
property matches the argument is returned. 


_NewEnum 


VT_UNKNOWN 


Returns the (Unknown interface of an object that implements the lEnumVar- 
iant interlace. 



25 



ResponseCodes Collection 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


ReadyCourrt (C) 


VT_I4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

The argument must take the form of an integer and the response code 
whose Value property matches the argument is returned. 


_NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object that implements the lEnum Var- 
iant interface. 
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Root Object 


5 


Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of items in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block rf all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VT.DISPATCH 

■ ■ 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object. 

Collections: 


SO 






The "NamedConfig" collection is a NamedCorrfig collection and contains all 
the named configurations, 275 configurations, and device templates. 

The "BlockTag" collection is a BlockTag collection and contains all the blocks 
in the database organized by tag. 


25 . 






The "DevicelD" collection is a DevicelD collection and contains all the 
devices in the database organized by unique identifier. 

The "DeviceTag" collection is a DeviceTag collection and contains all the 
devices in the database organized by tag. 


30 






The "PhysicalTag" collection is a PhysicalTag collection and contains all the 
devices in the database organized by HART tag. 

The "Net" collection is a Net collection and contains all the TCP/IP nodes. 


35 
40 


_NewEnum 


VT_UNKNOWN 


Returns the (Unknown interface of an object that implements the I Enum Var- 
iant interface. 










Tag Collection 




Property Name 


Return Type 


Description 


45 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 




ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


50 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 




Method Name 


Return Type 


Description 




item 


VT_D!SPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


55 






The Block object whose Tag property matches the argument is returned. 




_NewEnum 


NTTJJNKNOWN 


Returns the I Unknown interface of an object that implements the lEnum Var- 
iant interlace. 
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5 


UnitRelatlon Object 




Property Name 


Return Type 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCourrt (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 




ServerCourrt (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Name (R) 


VT_BSTR 


The unit relation's name. 




Itemld (R) 


VT 14 


The unit relation's item ID. 




Index (R) 


VTJ4 


The unit relation's index. 


20 


Method Name 


Return Type 


Description 




Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the collections 
provided by the object 

Collections: 


25 






The "Units" collection is a Relationltems collection and contains the param- 
eter on the left side of the unit relation. 

The "Member" collection is a Relationltems collection and contains the 
parameters on the right side of the unit relation. 


30 


NewEnum 


VTJJNKNOWN 


Returns the lUnknown interface of an object thatimplements the lEnumVar- 
iarrt interlace. ' 



35 



40 



45 



SO 
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UnitRelations Collection 


5 


t^t\Jy\2l\y name 


Return Tvne 


Description 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 


10 


ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of Hems in the collection. 




ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the Hems are not 
immediately available. 




Method Name 


Return Type 


Description 


15 


Item 


VT_D1SPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 


20 






If the argument begins with a $. the rest df the string must take the form of 
an integer. The unit relation whose Item Id property matches the argument is 
returned. 

If the argument begins with a digit, the string must take the form of an integer 
and the unit relation whose Index property matches the argument is 
returned. 


25 






Otherwise, the unit relation whose Name property matches the argument is 
returned. 




_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object trjatimplements the lEnumVar- 
iant interface. 


30 
35 






f 



40 



45 



50 
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VariableParajoeter Object 



Property Name 


Return TyP e 


Description 


Count (C) 


VT__I4 


The number of items in the 
collection. This property 
blocks until all the items in 
the collection dan be accessed 
without blocking. 


Ready Count (C) 


VT_I4 


The number of items in the 
collection that. can be 
accessed without— blocking, 
which may be less than the 
total number of items in the 
collection* 


ServerCount (N) 


VT_I4 


Same as the Count property 
except it does not block if 

all the *i t~ *»m*5 a t**» not 
immediately available. 


Name (R) 


VT_BSTR 


The parameter's (or record 
member ' s ) name . 


Memberld (R) 


VT_I4 


The parameter's (or record 
member's) member id. 


Itemld (R) 


VT 14 


The variable's item id. 


Paramlndex (R) 


VT_I4 


The parameter's (or array" 
element's) index. 
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tf* R 1" "1 n ^ 4 Afl 

xp Ul W^l 


value (r) (R) 


VT VARIANT 


The parameter's value. 


ValueAs String! f) 
\ tw 


VT_BSTR 


The parameter' s value as a 


I ype *kj 


V X X^B 


me parameter s type . 


lypeASbLring 


tw rj ctu 
V A_o*3 1 K 


ine parameter s type as a 
string. 


Size (R) 


VT_I4 


The parameter's size (in 
bytes) . 


ParamLabel (R) 


VT BSTR 


The parameter-specific label. 


Label (R) 


VT BSTR 


The variable-specific label. 


ParamHelp (R) 


VT BSTR 


The parameter-specific help. 


Help (R) 


VT BSTR 


The variable-specific help. 


Class (R) 


VT 14 


The parameter's class. 


Class AsSt ring (R) 


VT_BSTR 


The parameter's class as a 
string. 


Handling (R) 


VT_I4 


Returns the parameter's 
handling. 


Handl ingAsString 
(R) 


VT_BSTR 


The parameter's .handling as a 
string. 


ReadTimeout (R) 


VT 14 


The parameter's read time-out. 


WriteTimeout (R) 


VT_I4 


The parameter's write 
time-out. 


DisplayFormat (R) 


VT_BSTR 


The parameter's display 
format. 


Ed it Format (R) 


VT BSTR 


The parameter* s edit format . 


MinCount (R) 


VT 14 


The number of min values. 


MaxCount (R) 


VT 14 


The number of max values. 


MinValueN (R) 


VT^VAR I ANT 


One of the parameter's min 

values • V* XilUXuaLCs wnica uLxu 

value is to be returned and 
must take the form of an 
integer. 


MaxValueN (R) 


VT_VAR I ANT 


One of the parameter's max 
values. N indicates which max 
value is to be returned and 
must take the form of an 
integer. 
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'0 



Property Name 


Return Type 


Description 


EnumDescription 
(R) 


VT_BSTR 


The Description property of 
the Enumeration Value 
corresponding to the current 
value of the parameter. This 

DrooertV is onlv meaninrrfnl 4^ 

the parameter's type is 
ENUMERATED . 


EnumHelp (R) 


VT_BSTR 


The Help property of the 
Enumeration Value 
corresponding to the current 
value of the parameter. This 
property is only meaningful if 
the parameter' s type is 
ENUMERATED. 


Units <R) 


VT BSTR 


The parameter's units. 


Validity (R) 


VT 14 


The parameter's validity. 


IndexItemArray (R) 


VT_I4 


The Item ID of the Item Array 
which this variable indexes , 
if this variable is of type 
Index . 



25 



30 



35 



40 



45 



50 
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Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type 
VT_BSTR and returns one of the 
collections provided by the 
object. 

Collections : 

The n Enum n collection is an 
finumera t i onVa lues collect ion 
and contains the parameter's 
enumeration values. 

The "RespCode" collection is a 
ResponseCodes collection and 
contains* the .parameter's 
response codes . 

The "PreEdit" collection is a 
Methods collection and 
contains the parameter's 
pre-edit methods. 

The "PostEdit" collection is a 
Methods collection and 
contains the parameter' s 
post -edit methods. 

The " IndexedltemArray" 
collection is an ItemArray 
object which corresponds to 
the ItemArray parameter, if 
this variable is of type 
Index • 


_NewEnum 


VT_UNKNOWN 


Returns the I Unknown interface 
■oT ah object that implements 
the IEnumVariant interface. 


ExecutePreEdit 


VT_EMPTY 


Executes the parameter's 
pre-edit methods. 


ExecutePostEdit 


VT_EMPTY 


Executes the parameter' s 
post-edit methods. 
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WriteAsOneRelation Object 


Property Name 


Return Type 


Description 


Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in ine coueuuon can ue auccobcu wiuioui uiowrang. 


ReadyCourrt (C) 


VTJ4 


The number of items in the collection that can be accessed without block- 
ing, which may be less than the total number of items in the collection. 


ServerCount (N) 


VTJ4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


IMalTIc lly 


v i do i n 


The write as one relation's name. 


Itemld (R) 


VT_I4 


The write as one relation's item ID. 


Index (R) 


VTJ4 


The write as one relation's index. 


Method Name 


Return Type 


Description 


Item 1 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the items in the 
collection. 

Collections: 

The "Member" collection is a Relationltems collection and contains the 
parameters of the write as one relation. 


_NewEnum 


VT_UNKNOWN 


Returns the lUnknown interface of an object that implements the lEnumVar- 
iant interface. 
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WriteAsOne Relations Collection 


5 




- Return TvnA 


Dpcc r i ntl on 




Count (C) 


VTJ4 


The number of items in the collection. This property blocks until all the items 
in the collection can be accessed without blocking. 




ReadyCount (C) 


VTJ4 


The number of items in the collection that can be accessed without blocking, 
which may be less than the total number of Hems in the collection. 




ServerCount (N) 


VT_I4 


Same as the Count property except it does not block if all the items are not 
immediately available. 


15 


Method Name 


Return Type 


Description 


Item 


VT_DISPATCH 


Takes one argument of type VT_BSTR and returns one of the Hems in the 
collection. 


20 






If the argument begins with a $, the rest of aha must take the form of an inte- 
ger. The write as one relation whose Item id property matches the argument 
is returned. 

If the argument begins with a digit, the string must take the form of an integer 
and the write as one relation whose Index property matches the argument is 
returned. 


25 






Otherwise, the write as one relation whose Name property matches the 
argument is returned. 




_NewEnum 


VT_UNKNOWN 


Returns the 1 Unknown interface of an object that implements the lEnumVar- 
iant interface. 


30 









1. A field device management system (10) adapted for communicating with a field device (16) having device data 
associated therewith and with a device description storing a subset of the device data therein, the system compris- 
es ing: 

means for communicating with the field device; 

means for interpreting the device description to obtain the subset of the device data stored therein; means for 
40 storing a hierarchy of categories of information associated with the device data, including means associated 

with each of the categories for defining communication procedures related to the device data associated with 
that category; 

means for initiating a command related to a portion of the device data; 

45 

means for categorizing the command as related to one of the categories of the predetermined hierarchy of cat- 
egories of information; and 

means responsive to the categorizing means for controlling the communicating means and the interpreting 
so means in accordance with the communication procedures associated with the one of the categories. 

2. The field device management system of Claim 1. further including a database for storing another portion of the 
device data, means for interfacing with the database and further means responsive to the categorizing means for 
controlling the interfacing means in accordance with the communication procedures associated with the one of the 

55 categories. 

3. The field device management system of Claim 2. wherein the another portion of the device data includes data 
related to a past configuration of the field device. 
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4. The field device management system of Claim 2, .wherein the initiating means initiates a command to retrieve 
device data from one of the field device, the device description and the database. 

5. The field device management system of Claim 2. wherein the initiating means initiates a command to store device 
5 data in one of the field device and the database. 

6. The field device management system of Claim 2. wherein the initiating means initiates a command to have the field 
device perform a predefined function. 

10 7. The field device management system of Claim 1 , wherein the predetermined hierarchy of categories of information 
includes a category related to the physical connectivity of the field device and includes a category related to the 
configuration of the field device. 

8. The field device management system of Claim 1. wherein the field device includes a functional block defining one 
is of an input, an output and a control function of the field device and wherein the predetermined hierarchy of catego- 
ries of information includes a category defining the block of the field device. 

9. The field device management system of Claim 1 . wherein the predetermined hierarchy of categories of information 
includes means for specifying the interrelationship between a multiplicity of the categories of information and 

so wherein the controlling means includes means for sending messages between two of the multiplicity of the catego- 
ries of information according to the specified interrelationship to control the communicating means and the inter- 
preting means. 

10. The field device management system of Claim 1. wherein the storing means includes means for assigning a 
25 moniker to a selected one of the categories based on the position of the selected one of the categories within the 

hierarchy of categories of information. 

1 1 . The field device management system of Claim 1 . wherein the storing means includes a set of objects in an object- 
oriented programming paradigm. 

30 ... 

12. The field device management system of Claim 1 f wherein the communicating means includes further means for 
communicating with the field device through a portable communication device. 

13. A device management system (10) adapted to be coupled to a plurality of field devices (16) having field device 
35 information associated therewith, comprising: 

a library (60) that stores a device description associated with each of the plurality of field devices, wherein each 
of the device descriptions stores a portion of the field device information; 

40 means for identifying a hierarchy of categories of information related to the field device information; 

means for communicating with the plurality of field devices based on the hierarchy of categories of information; 
and 

45 means for retrieving field device information from the device descriptions based on the hierarchy of categories 
of information. _ . _ . _ . - 

14. The device management system of Claim 1 3, further including a database capable of storing another portion of the 
field device information and means for interfacing with the database based on the hierarchy of categories of irrfor- 

so mation. 

15. The device management system of Claim 14, wherein the identifying means includes means associated with each 
of the categories of information for storing field device information associated with that category of information and 
means associated with each of the categories of information for defining the operation of the controlling means or 

55 the retrieving means or the interfacing means with respect to the field device information associated with that cat- 
egory of information. 

16. The device management system of Claim 1 5, wherein the storing means and the defining means comprise a set of 
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objects in an object-oriented programming paradigm. 

17. The device management system of Claim 13, wherein one of the device descriptions includes field device informa- 
tion related to the communication format of one of the plurality of field devices. 

5 

18. A system (10) for communicating with a plurality of field devices (16), each of which has device information asso- 
ciated therewith, comprising: 

a library (60) which stores a device description for each of the plurality of field devices, wherein each of the 
10 device descriptions includes a portion of the device information pertaining to one of the plurality of field 

devices; 

means for communicating with the plurality of field devices and with the device descriptions stored in the 
library; and 

15 

means for categorizing the device information associated with each of the plurality of field devices into a mul- 
tiplicity of predetermined categories, wherein each of the multiplicity of predetermined categories includes; 

means for storing device information associated with the category, and 

20 

means for controlling the communicating means with respect to the device information associated with the cat- 
egory. 

1 9. The system of Claim 1 8, further including a database which stores another portion of the device information for one 
25 of the plurality of field devices and wherein the communicating means includes means for interfacing with the data- 
base. 

20. The system of Claim 18, wherein the multiplicity of predetermined categories comprises a hierarchy of categories 
and wherein the categorizing means includes means for defining the interrelationship between each of the catego- 

30 ries of the hierarchy of categories of information. n 

21. The system of Claim 18, wherein each of the device descriptions is written in accordance with a device protocol 
and wherein the device protocol associated with a first one of the device descriptions is different than the device 
protocol associated with a second one of the device descriptions. 

35 



40 



45 



SO 



55 



75 



EP0 961 184 A2 



30- 



31- 
32- 



Fietdbus 
Interface 



45 



1 



FIELD MANAGEMENT SOLUTIONS SYSTEM 



Display 



-{Printei 



4 Keyboard! fl^. 



Operating 
System 
and CPU 



AAA 



^36 

4 ► 



Modem 



44 



12 



Hand Held 
Communicator 



Hand Held 
Communicator 



46 



4 2 



HART 
Device 



•16 



18 



HART 
Device 



^22 



Fieldbus 
Device" 



HART A 
Device 



^20 



24 



Conventional 
Device 



Memory 



FMS 
Database 



38 
^40 



48 



Ethernet 



15 



FMS 



14 



DISTRIBUTED 
' CONTROL 
SYSTEM 



FIG. 1 



76 



I 



EP0 961 184 A2 



10 



I 



Printer 



Display 



30' 



Keyboard 

— r 



T 



FMS Applications 



56 



Core 



Current 



Windows 
Operating 
System 



32 
6 5^ 



rSyste 



Add -on 



— 50 
52 

-54^~ 



34 
58^ 

66 

\ 



Control 



60 



DCI 



68- 



62 



FMS 
Database 
Interface 



64 

4- 



■4 — P 



ODBC 



OLE Objects 



Device 
Server 



74- 



72 



OLE Objects 



Database 
Server 



-70 



DDS 



Smart Device 
Comm. 
Interface 



Device 
Description 
Library 



76 



FMS 
Database 
Interface 

V 80 



Smart Devices -| 12 



FMS 

Database 



40 



FIG. 



77 



EP0 961 184 A2 




78 



EP 0 961 184 A2 



"Param" 



"Unit" 



•Database* 



( Para meters V Unit- A ( Database- \ / Ref 
^ r-a r a meters ^ Rela '^ on J I Parameters J V lot 



■Refresh" 



Param Name 



Unit name 



Unit Relation 



.'Units" 



( 



RefreshRe 
ions 



Database 
Parameter 



Name 

) 



Refresh 
Name 



3 



Refresh Rel at ion 



'Members' 



'Left 



/ Rela tion-A A Relation- V / Relation- A ( 
V Items )\ Items J V Items J \ 



"Right' 



Index 



Index 



Index 



Relation- 
Items 

Index 



) 



•IndexedlternAnray "E num 



(itemArray) ^ 



Enumeration 
Values 



) ( 



"PreEdif 
Methods) 



lt Enum Value 

(Enumeration \ f Method } 
Value J Vs J 



Index 



'Actions* 

( Method j 



FIG. 4A 



79 



EP0 961 184 A2 



(Block) 



( 



Named A 
Config J 



'Item Array" 



•Collection" 



•Menu" 



"Method" 



( ItemArrcys ) ( Collections } (Menus ) (Methods' ) 



Item Array 
Name 



Collect ion Menu Method 
_ Narpe _ j Na me | Name 

(itemArray^ -p ^ collect ion ) ( Menu )♦-[-»( Method ) 




"PreEdit" 



(Methods ) 



index 



(Method ) 




I 



(variablePara meter ) 
I 



"Post Edit" 



(Methods ) 



Index 



( Method ) 



( RecordParameter ) 



"Resi 
Co 



X'Member" 

( Members ) 

t Member 
' Name 



m "RespCode* 
( ResponseCodes ) 



PIG. 4B 



Response Code 

^ Valu e 

( ResponseCode^- 



80 



EP0 961 184 A2 



CD 
T 

U. 



E 
o 



"EditDisplay* 
^EditDisplays ) 



WAO' 



AVriteAsOne 



Relations 



Edit Displa y 
Name 



■♦ (EditDisplay ) 



I 



"Post Ed it" 



"Display 



Index 



(Method) 



Index 



i 







"Element" 






( Elements J 




Element 


Number 









Index 



Write As One 



Name 



c 



Write As One A 
Reiat ion V 



Member" 



(Relotionltems } 
I Index 



FIG. 4C 



81 



EP0 961 184 A2 



<40 



TRANSACTION DATABASE 



-202 
-202 

-202 



-200 



202 



FMS DATABASE (FIG. 2) 



FIG. 5 



82 



EP0 961 184 A2 



FIG. 6 



BlockKey 

TlmeKey 

ParamName 

ParamKind 

ValueMode 

ParamDataType 
ParamDa t as i ze 

ParamPata 

Archived 

Expected 



>204 
■205 
-206 
■207 
+-208 
-209 
-210 
-211 
J— 212 
3" 213 



^202 



83 



EP0 961 184 A2 



C start ) 



FIG. 7 



CONNECT FMS TO A 
DEVICE AND 
RETRIEVE THE 

ACTUAL STATE OF 
THE DEVICE. 



■220 



^222 



)OES THE ACTUAL STATE OF 
THE DEVICE EQUAL THE 
EXPECTED STATE OF THE' 
DEVICE? 



228 



1 / 



ADD A RECORD OF AN 
UNEXPECTED CHANGE TO 

THE TRANSACTION 
DATABASE. 



PERMIT OPERATOR TO MAKE 
ADDITIONAL CHANGES TO THE 
DEVICE AND. IF ANY ARE MADE/ 
RECORD THEM IN THE 
TRANSACTION DATABASE AS 
EXPECTED CHANGES. 



APPLY CHANGE TO DEVICE. 



-224 



230 



ADD RECORD OF CHANGE TO 
TRANSACTION DATABASE. 



•226 



23 2 




84 



EP0 961 184 A2 



HANDHELD DEVICE CONNECTS 
TO FMS, AND FMS STORES A 
CONFIGURATION THEREIN 



•240 



HANDHELD COMMUNICATOR 
CONNECTS TO DEVICE AND 
APPLIES THE NEW 
CONFIGURATION TO THE DEVICE 



C 



-24 2 



'■ REPORT BACK -L 

i i 



STOP 



FIG. 8 



85 



EP0 961 184 A2 




FIG 



LOAD NEXT 
UNRECONCILED 
TRANSACTION 
RECORD TR FROM 
SECONDARY FMS 
INTO PRIMARY FMS 



-252 




INSERT TR IN FMS1 IN 
CHRONOLOGICAL 
ORDER. 



REPLACE 
UNEXPECTED 
CHANGE WITH TR. 



APPEND TR 
AT END OF 
FMS1. 







>66, 








DISCARD TR. 



86 



EP0 961 184 A2 



Q START ^ 



1 


r 


FMS READS ACTUAL STATE OF 
DEVICE FROM HANDHELD - 
DEVICE 




r 



270 



272 




274 



APPEND THE ACTUAL STATE OF 
THE DEVICE TO THE END OF THE 
TRANSACTION DATABASE AS AN 
UNEXPECTED CHANGE. 



FIG. 10 



87 



EP0 961 184 A2 



3Q0 



Master 
Control 



302 

Device 
Control 



r 



304 



Block 
Control 



Master 
Time - 
Line 
Control 



Parameter 
Control 



Ti me 
L i ne 
Control 



301 



306 



308 



FIG. 11 



88 



EP0 961 184 A2 



Control Initialization 



Define Control Type 


— 31 0 




r ■ 




Define User Interface Attributes - 


311 








Define Refreshing Rate 
Connect To Root Object 


312 



FIG. 12 



89 



EP0 961 184 A2 



Control Operation 



Connect To 
OLE Object 



■313 



Initialize/Establish User 
Interface on Display 



-314 




FIG. 13 



90 



EP0 961 184 A2 




318 



Interpret Message 


Read 
OLE 
Object 
Data 


Change 
Parameter/ 
Root Value 


Change 

User 
Interface 



322 




-316 



FIG. 14 



91 



EP0 961 184 A2 



Non-Blocking 
Non-Periodic 



Read OLE 
Object Data 
From OLE 
Object 



324 
V 



Send Message to 
Retrieve Object 
Properties From 
OLE Object 



326 
V 




330 



Wait for 
OLE Object 
Data From 
OLE Block 



Non-Blocking 
Periodic 



332 



Store In Control Cache 



334 



Change User 
Interface if Necessary 



336 



Notify Application ff 
Necessary 



| Return ] 



PIG. 15 



92 



EP0 961 184 A2 




Change 
Parameter/Root 
Value 



338 



J 



Notify 
User/Application 
That Parameter 
Or Root Value 
Not Writable 



-342 



FIG. 16 



Notify 
User/Application 
That New 
Parameter or 
Root Value Not 
Writable 



346 



Send Change 
Message To 
Parameter or Root 
Object 



Wait For 
Return 
Message 



350 



Return 



352 




Yes With _ 
Condition" 



358 



Get Response Code 



Indicate To 
Application/User 
That Change Made 



Indicate To 
Application/User 
That Change Not 
Made And Reason 
for Rejection 



Indicate To 
A£>pIication/User 
That Change Made 
And Response 
Code 



■\ — 

360 



Return 



93 



EP0 961 184 A2 



Change User 
Display 
Interface 



Change User 
Display 
Interface 
Attributes 



362 



364 




366 



PIG. 17 



94 



EP0 961 184 A2 




370 



Check to Determine 
If User Action 
Meaningful 



Yes 



— Nc 



372 



Ignore User 
Action 



Interpret Message 


Change 


Change 


Parameter/ 


User 


Root Value 


Interface 


/— i 1 





76 



■374 



378 



□ 0 



FIG. 18 



95 



EP0 961 184 A2 



9. 



Interpret Message - 


-3 80 


Change 


Read 




Message 


Return 





38 2 



390 




3 84 



FIG. 19 



96 



I 



EP 0 961 184 A2 



400 




S 1181 OO S 3044 OO 



FIG. 20 



Application 



a 



Label Text lEdit Text | UnitsText 



Pressure 15.55 



Temperature 1QO. 2 



]psi 

]DegC 



Mode [ 



.inear 



Logarithmic 
Linear 
Exponential 
Square Root 
Other 



FIG. 21 



97 



EP0 961 184 A2 




FIG. 22 



4 20 



I 



+ 



424 



PAST I 


/ 


12/10/95 


1 :1b 




12/10/95 


12:30 


1 /15/96 


16:40 



422 



i 



■f 



I 



iPRESENTj 



424 



TEMP | 4Q I °C - 
PRESS | 12 I PSI- 



430 



432 



TEMP 



30 



PRESS I 15 | PSI 



• c- ^-440 
442 



FIG. 23 



EP0 961 184 A2 



C s ™" ) 



INmAUZE THE 
STATE {S} OF THE 
BLOCK TO NUL 



J. 



450 



SET TIME OF STATE 
{S} TO THE VIEWTIME. 



452 




454 



458 



IDENTIFY THE NEXT 
PARAMETER P IN 
THE BLOCK 





. ^ 6 


THE STATE 1 OF THE 
BLOCK AT THE VIEWTIME 
IS {S>. 




r 



( STOP ) 



SEARCH THE TRANSACTION DATABASE 
IN REVERSE-CHRONOLOGICAL ORDER 
BEGINNING AT THE VIEWTIME TO FIND 

THE LATEST CHANGE TR AT OR BEFORE 
THE VIEWTIME. 



. AGO 



ADD P. WITH THE VALUE 
OF P SET BY THE 
CHANGE TR, TO {S}. 



462 



FIG. 24 



99 



(19) 



J 



(12) 




(88) Date of publication A3: 

31.05.2000 Bulletin 2000/22 



EuropSisches Patent a mt 
European Patent Office 
Off ice europgen des brevets (11) EP0 961 184 A3 

EUROPEAN PATENT APPLICATION 

(51) int. CI. 7 : G05B 19/418 



(43) Date of publication A2: 

01.12.1999 Bulletin 1999/48 

(21) Application number: 99115002.0 

(22) Date of filing: 05.02.1 997 



(84) Designated Contracting States: 


(72) Inventors: 


AT BE CH DE. DK ES Fl FR GB GR IE IT LI LU NIC 


• Sharpe, Richard R., Jr. 


NL PT SE 


Lakevllle, MN 55044 (US) 


Designated Extension States: 


• Helens, Craig R. 


AL LT LV RO SI 


Minneapolis, WIN 55419 (US) 




• Westbrock, Jon 


(30) Priority: 06.02.1996 US 599371 


Eagan, MN 55423 (US) 


12.12.1996 US 764057 


• Olson, Gene H. 


04.12.1996 US 759387 


Minneapolis, MN 55419 (US) 




• Bruck, Robert 


(62) Document number(s) of the earlier application(s) in 


Apple Valley, MN 55124 (US) 


accordance with Art. 76 EPC: 


97904119.1 / 0 885 412 


(74) Representative: 


(71) Applicant: 


Bohnenberger, Johannes, Dr. et al 


Meissner, Bolte & Partner 


Fisher-Rosemount Systems, Inc. 


Widenmayerstrasse 48 


Austin, Texas 78754 (US) 


80538 MOnchen (DE) 



(54) System and method for managing a transaction database of records of changes to field 
device configurations 



(57) A computer-based database management 
method permits management of a configuration data- 
base associated with one of a plurality of devices. Each 
device has a variable configuration which includes at 
least one adjustable parameter. The method includes 
the steps of selecting a particular device, selecting a 
particular parameter of the particular device, assigning 
a particular value for the particular parameter at a par* 
ticular time, communicating the particular value for the 
particular parameter to the particular device at the par- 
ticular time, creating a transaction record, and storing 
the transaction record in a configuration database. The 
transaction record includes an identifier uniquely identi- 
fying the particular device and further specifies the par- 
ticular parameter of the particular device, the particular 
value for the particular parameter, and the particular 
time at which the particular value is to be applied to the 
particular parameter. 



SB 



3QO 



Master 
Control 



302 



Device 
Control 



7^ 



Block 
Control 



Master 
Time - 
Line 
Control 



Parameter 
Control 



301 



Time 
Line 
Control 



308 



FIG. 11 



Primed by Xerox (UK) Business Services 
2.16.7 (HRS)/3 6 



EP0 961 184 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 99 11 5002 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASS FIC ATION OF THE 
APPLICATION (lnLCI.7) 



P.X 



WO 96 07957 A (SQUARE D CO) 
14 March 1996 (1996-03-14) 

* the whole document * 

WO 95 26527 A (OXY DRY CORP) 

5 October 1995 (1995-10-05) 

* the whole document * 

FR 2 692 701 A (AEROSPATIALE) 
24 December 1993 (1993-12-24) 

* the whole document * 

DE 42 10 376 A (MAZDA MOTOR) 
1 October 1992 (1992-10-01) 

* the whole document * 

W0 95 09387 A (DOW BENELUX) 

6 April 1995 (1995-04-06) 

* the whole document * 

EP 0 434 986 A (SIEMENS AG) " 
3 July 1991 (1991-07-03) 

* the whole document * 



1,18 



1,18 



1,18 



1,18 



1,18 



1,18 



G05B19/418 



TECHNICAL FIELDS 
SEARCHED (IM.CL7) 



G05B 



The present search report has been drawn up for all claims 



Piaoa at •••rch 



THE HAGUE 



Dm* at correction ot ttx March 

11 April 2000 



Hauser, L 



CATEGORY OF CfTED DOCUMENTS 

X : particularly relevant I tsken alone 
Y : parboularty relevant tf combined with another 
dooumant of tha »ama category 

A : technological background 
O : non-writtan diaoloaure 
P : intermadiata document 



T : thaory or prinejple undaftying tha invention 
E : earlier patent document, but pub b« had on, or 

after tha filing date 
O : document cted in the application 
L : doeumant cited for other reasons 

ft : marnbar of the eame patent lamfty, corresponding 
dooument 



2 



EP 0 961 184 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 99 11 5002 



This annex lists the patent family members relating to the patent documents cited in the above-mentioned European search report. . 
The members are aa contained in the European Patent Office EDP file on 

The European Patent Office rs in no way liable for these particulars which are merely given for the purpose of information. 

11-64-2000 



Patent document 
cited in search report 



Publication 
dale 



Patent family 
members) 



PubKoe t ion 
date 



W0 9607957 


A 


"1 A 

14 


-03- 


-1996 


US 


5611039 A 


11-83-1997 












CA 


2197876 A 


14-93-1996 












EP 


0777870 A 


11-06-1997 












JP 


10505179 T 


19-85-1998 












US 


5706455 A 


06-01-1998 












US 


5675756 A 


07-10-1997 












US 


5929855 A 


27-07-1999 


W0 9526527 


A 


05 


-10 


-1995 


NONE 






FR 2692701 


A 


24 


-12 


-1993 


US 


5579511 A 


26-11-1996 


DE 4210376 


A 


01 


-10 


-1992 


JP 


4303255 A 


27-10-1992 












KR 


9613360 B 


04-10-1996 












US 


5841657 A 


24-11-1998 


W0 9509387 


A 


06 


-04 


-1995 


US 


5631825 A 


20-05-1997 












AU 


7657194 A 


18-04-1995 












EP 


0721611 A 


17-07-1996 












JP 


9503086 T 


25-03-1997 


EP 0434986 


A 


03 


-07 


-1991 


JP 


4152403 A 


26-05-1992 



For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



BNSDOCID: <EP 0961184A3 I > 



